Производительность Python - необходимо ли было когда-либо переписывать в чем-то еще?

Я нахожусь в процессе перезаписи программы OpenKore Perl в Python под именем Erok (реверс оригинала Кора ). До сих пор Python оказывается полным лучшим языком, особенно из-за его мощных строковых функций парсинга, которые не требуют использования регулярных выражений, которое действительно ускоряет большой его парсинг файла.

Да, я имею. Я записал программу количества строки для двоичного файла (снабженный префиксом длину, а не разграниченный) выходной файл BCP однажды и закончил тем, что имел необходимость восстановить его в C, потому что Python каждый был слишком медленным. Эта программа была довольно маленькой (только потребовалось несколько дней для переписывания его в C), таким образом, я не потрудился пытаться создать гибридное приложение (связующее звено Python с центральными стандартными программами, записанными в C), но это также будет жизнеспособным маршрутом.

объемное приложение А с производительностью критические биты могут быть записаны в комбинации C и высокоуровневого языка. Можно записать критические по отношению к производительности части в C с интерфейсом к Python для остальной части системы. БОЛЬШОЙ ГЛОТОК , Пирекс или Повышение. Python (если Вы используете C++) все обеспечивают хорошие механизмы, чтобы сделать инфраструктуру для Вашего интерфейса Python. API C для python более сложен, чем это для Tcl или Lua, но не неосуществим создать вручную. Для примера изготовленного вручную API Python/C проверьте cx_Oracle.

Этот подход использовался на множестве успешных приложений, возвращающихся до 1970-х (что я знаю). Mozilla был существенно записан в JavaScript вокруг базового механизма, записанного в C. Несколько пакеты CAD , Прокладочный лист (технический документ, публикующий систему) и конечно EMACS, существенно записаны в LISP с центральным C, ассемблером или другим ядром. Довольно много коммерческого применения и приложений с открытым исходным кодом (например, Chandler или Передняя Арена SunGard ) используют встроенные интерпретаторы Python и реализуют существенные части приложения в Python.

РЕДАКТИРОВАНИЕ: В rsponse к комментарию голландского Masters, сохраняя кого-то с C или навыками программирования на C++ в команде для проекта Python дает Вам опцию записи части приложения для скорости. Области, где можно ожидать получать значительное увеличение производительности, - то, где приложение делает что-то очень повторяющееся по большой структуре данных или большому объему данных. В случае счетчика строки выше его должен был вдохнуть серию файлов в общей сложности несколько гигабайтов и пройти процесс, где это считало переменный префикс длины и использовало это для определения длины поля данных. Большинство полей было коротко (всего несколько байтов длиной). Это было несколько разрядно-извилистым и очень низким уровнем и повторяющийся, который сделал его естественным пригодным для C.

Многие библиотеки Python такой как [1 114] numpy, cElementTree или cStringIO использует оптимизированное ядро C с API Python, который упрощает работу с данными в агрегате. Например, numpy имеет матричные структуры данных и операции, записанные в C, которые делают всю тяжелую работу и API Python, который предоставляет услуги на совокупном уровне.

Следующая ссылка обеспечивает на идущем сравнении между многими языками программирования. Это должно дать Вам общее представление о некоторых достоинствах и недостатках Python через различные проблемные области.

Игра

Я когда-то должен был записать генератор псевдослучайного числа для средства моделирования. Я записал его в Python сначала, но Python оказался слишком медленным; я закончил тем, что переписал его в C, и даже который был медленным, но совсем не столь же медленным как Python.

К счастью, довольно легко соединить мостом Python и C, таким образом, я смог записать PRNG как модуль C и все еще записать остальную часть средства моделирования в Python.

Месяц назад мне записали эту небольшую программу в Python (для работы), который анализирует журналы. Когда тогда количество файлов журнала выросло, программа, которая, как начинают, была очень медленной, и я думал, что мог переписать его в Java.

я был очень интересен. Потребовался целый день для миграции того же алгоритма от Python до Java. В конце дня несколько пробных версий сравнительного теста показали мне ясно, что программа Java была приблизительно на 20% / 25% медленнее, чем ее дубликат Python. Это было удивление мне.

Запись во второй раз алгоритм также показал мне, что некоторая оптимизация была возможна. Таким образом за два часа я полностью переписал все это в Python, и это было приблизительно на 40% быстрее, чем исходная реализация Python (следовательно заказы времени быстрее, чем версия Java, которую я имел).

Так:

1. Python является медленным языком, но тем не менее это может быть быстрее для определенных задач, что другие, предположительно, более быстрые языки

2. , Если необходимо провести время, пишущий что-то на языке, выполнение которого быстрее, но чье время разработки медленнее (большинство языков), рассмотрите использование того же времени, чтобы проанализировать проблему, поиск библиотек, профиля и затем записать лучший код Python.

Нет, я никогда не должен был переписывать. На самом деле я начал использовать Python в 8.5 майя. Перед 8 майя единственный доступный язык сценариев был созданным в MEL (Язык Выражения майя). Python на самом деле быстрее, чем созданный на языке, который он обертывает.

способность Python работать со сложными типами данных также сделала его быстрее, потому что MEL может только сохранить единственные размерные массивы (и никакие указатели). Это потребовало бы, чтобы многомерные массивы фальсифицировались или использующий несколько параллельных массивов, или при помощи медленной конкатенации строк.

Я работал некоторое время теперь, разрабатывая приложение, которые воздействуют на большие структурированные данные, сохраненные в several-gigabytes-thick-database и хорошо, Python достаточно хорош для этого. Приложение имеет клиент GUI со множеством средств управления (списки, деревья, ноутбуки, виртуальные списки и больше), и консольный сервер.

у Нас были некоторые проблемы производительности, но те были главным образом связаны больше с плохим дизайном алгоритма или ограничениями механизма базы данных (мы используем Oracle, SQL MS, MySQL и имели короткий роман с BerkeleyDB, используемым для оптимизации скорости), чем к самому Python. Как только Вы знаете, как пользоваться стандартными библиотеками (записанный в C) правильно, можно сделать код действительно быстрым.

, Поскольку другие говорят - любое вычисление интенсивный алгоритм, код, который зависит от заполнения битами, некоторая память ограничила вычисление - может быть сделан в необработанном C/C++ для сохранения ЦП/памяти (или любые другие приемы), но целое взаимодействие с пользователем, вход, обработка базы данных, обработка ошибок - все, что подает приложение, на самом деле запущенное, может быть записано в Python, и это поддержит скорость отклика и достойную общую производительность.

Я разрабатываю в Python в течение нескольких лет теперь. Недавно я должен был перечислить все файлы в каталоге и создать структуру с именем файла, размером, атрибутами и датой модификации. Я сделал это с os.listdir и os.stat. Код был довольно быстр, но чем больше записей в каталогах, тем медленнее мой код стал сравненным с другим filemanagers список того же каталога, таким образом, я переписал код с помощью БОЛЬШОГО ГЛОТКА/C++ и был действительно удивлен, насколько быстрее код был.

Я раньше моделировал много вещей в Python для того, чтобы сделать вещи как обработка журнала. Когда они не работали достаточно быстро, я перепишу их в ocaml.

Во многих случаях, Python был прекрасен, и я был доволен им. В некоторых случаях, поскольку это начало приближаться к 23 часам, чтобы сделать журналы дней, я доберусь до перезаписи.:)

я хотел бы указать, что даже в тех случаях, я, возможно, был более обеспечен просто профилирование кода Python и нахождение более счастливой реализации Python.

Этот вид вопроса, вероятно, запустит религиозную войну среди людей языка, таким образом позвольте мне ответить на него немного по-другому.

Для большинства случаев в сегодняшних вычислительных средах Ваш выбор языка программирования должен быть на основе того, что можно программировать эффективно, программа хорошо и что делает Вас счастливыми не рабочие характеристики языка. Кроме того, оптимизация должна обычно быть последним беспокойством при программировании любой системы.

типичный Python способ сделать вещи состоят в том, чтобы начать писать Вашу программу в Python и затем если Вы замечаете, что страдание производительности представляет приложение и пытается оптимизировать горячие точки в Python сначала. Если оптимизация кода Python все еще не достаточно хороша области кода, которые пригибают Вас, должен быть переписан как модуль Python в C. Если даже, после всего из которого Ваша программа не достаточно быстра, можно или изменить языки или взгляд на увеличение масштаба в аппаратных средствах или параллелизме.

Это - длинный ответ, для ответа на вопрос непосредственно; нет, Python (иногда с расширениями C) был достаточно быстр для всего, что мне нужен он, чтобы сделать. Единственное время, которое я действительно опускаю в C, должно заставить доступ наполнять это, donesn't имеют привязку Python.

Редактирование: Мое образование является программистом Python в большом .com, где мы используем Python для всего от фронтенда наших веб-сайтов полностью вниз ко всем системам вспомогательного офиса. Python является в значительной степени языком корпоративного класса.

Каждый раз, когда я нахожу узкое место Python, я переписываю тот код в C как модуль Python.

, Например, у меня есть некоторые аппаратные средства, которые отправляют пиксели изображения как 4 байта 0RGB. Преобразование 8M от 0RGB до RGB в Python занимает слишком много времени так, я переписал его как модуль Python.

Запись Python (или другие высокоуровневые языки) намного быстрее, чем запись в C, таким образом, я использую Python, пока я не могу.

Не до сих пор. Я работаю на компанию, которая имеет молекулярный механизм моделирования и набор программ, записанных в Python для обработки больших наборов данных мультигигабайта. Все наше аналитическое программное обеспечение теперь пишется в Python из-за огромных преимуществ в гибкости разработки и время.

, Если что-то не достаточно быстро, мы представляем его с cProfile и находим узкие места. Обычно существуют одна или две функции, которые поднимают 80 или 90% времени выполнения. Мы тогда берем те функции и переписываем их в C, что-то, что Python обесточивает легкий с его API C. Во многих случаях это приводит к порядку величины или большему количеству ускорения. Проблему уводят. Мы тогда продолжаем наш веселый путь продолжить писать все остальное в Python. Промывка и повторение...

Для всех модулей или классов мы склонны использовать Boost.python, это может быть определенным переносом, но в конечном счете работает хорошо. Если это - просто функция или два, мы иногда встраиваем его с scipy.weave, если проект уже использует scipy.

В то время как в uni мы писали систему машинного зрения для анализа поведения человека на основе видеоклипов. Мы использовали Python из-за превосходного PIL, чтобы ускорить разработку и позволить нам получить легкий доступ к фреймам изображения, которые мы извлекли из видео для преобразования в массивы и т.д.

Для 90% того, что мы хотели, это было прекрасно и так как изображения были довольно низким разрешением, скорость не была плоха. Однако несколько процессов потребовали некоторых сложных попиксельных вычислений, а также сверток, которые являются известно медленными. Для этих конкретных областей мы переписали самые внутренние части циклов в C и просто обновили старые функции Python для вызывания функций C.

Это дало нам лучший из обоих миров. У нас была простота доступа к данным, который обеспечивает Python, который включил для разработки быстро, и затем скорость прямолинейного перемещения C для самых интенсивных вычислений.

Добавление моих 0,02$ для записи.

Моя работа включает разрабатывающие числовые модели, которые работают 100's гигабайтов данных. Тяжелые проблемы находятся в предложении генерирующего доход решения быстро (т.е. время выхода на рынок). Чтобы быть коммерчески успешным, решение также имеет к , выполняются быстро (вычислите решение за минимальное количество времени).

Для нас Python, оказалось, был отличным выбором разработать решения по причинам, обычно цитируемым: быстрое время разработки, выразительность языка, богатые библиотеки, и т.д. Но удовлетворять потребности скорости выполнения, мы приняли 'Гибридный' подход, который уже упомянули несколько ответов.

1. Используя numpy для в вычислительном отношении интенсивных частей. Мы добираемся в 1.1x до 2.5x скорость 'собственного' решения C++ с numpy с меньшим количеством кода, меньшим количеством ошибок, и более короткое время разработки.
2. Соление (сериализация объекта Python) промежуточное звено заканчивается для уменьшения перерасчета. Природа нашей системы требует, чтобы несколько переступили через те же данные, таким образом, мы 'запоминаем' результаты и снова используем их, если это возможно.
3. Профилирование и выбор лучших алгоритмов. Это было сказано в других ответах, но я повторю его: мы хлещем cProfile и попытку заменить горячие точки лучшим алгоритмом. Не применимый во всех случаях.
4. Движение к C++. Если вышеупомянутые сбои затем мы называем библиотеку C++. Мы используем PyBindGen для записи наших оберток Python/C++. Мы нашли это намного выше БОЛЬШОГО ГЛОТКА, SIP и Повышения. Python, поскольку это производит прямой Python C код API без промежуточного слоя.

Чтение этого списка Вы могли бы думать, "Что переделывает много из! Я просто сделаю это в [C/C ++/Java/assembler] в первый раз вокруг и буду сделан с ним".

Позволяют мне рассмотреть его в истинном свете. Используя Python мы смогли произвести рабочее генерирующее доход приложение через 5 недель, которые, на других языках, ранее потребовали 3 месяцев для проектов подобного объема. Это включает время, должен был оптимизировать части Python, которые мы нашли, чтобы быть медленными.

Это - намного более трудный вопрос для ответа, чем люди готовы признать.

, Например, может случиться так, что я в состоянии записать программу, которая работает лучше в Python, чем это делает в C. Ошибочным заключением из того оператора является "Python, поэтому быстрее, чем C". В действительности это может быть, потому что у меня есть намного более свежий опыт в Python и его лучших практиках и стандартных библиотеках.

На самом деле никто не может действительно ответить на Ваш вопрос, если они не уверены, что могут создать оптимальное решение на обоих языках, которое маловероятно. Другими словами, "Мое решение C было быстрее, чем моим решением Python" не является то же, поскольку "C быстрее, чем Python",

я готов держать пари, что Guido Van Rossum, возможно, записал решения Python для adam и проблем Dustin, которые работали вполне хорошо.

Мое эмпирическое правило - то, что, если Вы не пишете вид приложения, которое требует, чтобы Вы считали такты, можно, вероятно, достигнуть приемлемой производительности в Python.

Можно всегда писать части приложения в Python. Не каждый компонент одинаково важен для производительности. Python интегрируется легко с C++ исходно, или с Java через Jython, или с.NET через IronPython.

Между прочим, IronPython более эффективен, чем реализация C Python на некоторых сравнительных тестах.

При реализации специализированного сервера кэш-памяти для определенного типа данных бэкенд устройства хранения данных был бы большей эффективной памятью, и время поиска могло быть уменьшено разрядными мудрыми операциями поиска (т.е.: O (1) поиски).

Я записал, что вся реализация протокола и управляемый событиями демон расстаются с Python в течение 2 дней, давая нам достаточно времени для тестирования на функциональности и фокусируясь на производительности, в то время как команда проверяла соответствие протокола и другие биты.

Данный инструменты как Пирекс, реализовывая C расширения для Python рядом с тривиальным для любого разработчика, немного испытанного в C. Я переписал Основание основанный на дереве бэкенд устройства хранения данных в C и сделал это модулем Python с Пирексом в течение дня. Использование памяти для 475K префиксов перешло по сравнению с 90 МБ к 8 МБ. Мы получили 1 200%-й переход в производительности запросов.

Сегодня, это приложение работает с pyevent (интерфейс Python для libevent), и новый бэкенд устройства хранения данных обрабатывает 8 000 запросов в секунду на скромном одноядерном сервере, работая как единственный демон процесса (благодаря libevent) потребление меньше чем 40 МБ памяти (включая интерпретатор Python) при обработке 300 + одновременные соединения.

Это - проект, разработанный и реализованный к производственному качеству меньше чем за 5 дней. Без Python и Пирекса, это заняло бы больше времени.

Мы могли иметь, диагностируют проблему производительности, просто используя более мощные серверы и переключаются на модель мультипроцесса/мультиэкземпляра при усложнении кода и задач администрирования, сопровождаемых с намного большим объемом потребляемой памяти.

Я думаю, что Вы на правильном пути для движения с Python.

Let's make some reasonable assumptions:

(1) You really want to replace any run of whitespace characters with a single space (a run is of length 1 or greater).

(2) You would like the same code to work with minimal changes under Python 2.X with unicode objects.

(3) You don't want your code to assume things that are not guaranteed in the docs

(4) You would like the same code to work with minimal changes with Python 3.X str objects.

The currently selected answer has these problems:

(a) changes " " * 3 to " " * 2 i.e. it removes duplicate spaces but not triplicate, quadruplicate, etc spaces. [fails requirement 1]

(b) changes "foo\tbar\tzot" to "foobarzot" [fails requirement 1]

(c) when fed a unicode object, gets TypeError: translate() takes exactly one argument (2 given) [fails requirement 2]

(d) uses string.whitespace[:-1] [fails requirement 3; order of characters in string.whitespace is not guaranteed]

(e) uses string.whitespace[:-1] [fails requirement 4; in Python 2.X, string.whitespace is '\t\n\x0b\x0c\r '; in Python 3.X, it is ' \t\n\r\x0b\x0c']

The " ".join(s.split()) answer and the re.sub(r"\s+", " ", s) answer don't have these problems.

Да, дважды:

• Приложение аудио DSP, которое я полностью переписал на C ++, потому что не мог получить соответствующую производительность в Python; Я не считаю реализацию Python потраченной впустую, потому что она позволила мне очень легко прототипировать концепцию, а перенос на C ++ прошел гладко, потому что у меня была рабочая эталонная реализация.

• Проект процедурного графического рендеринга, в котором создание больших 2D текстурных карт в Python занимало много времени; Я написал C ++ DLL и использовал ctypes / windll, чтобы использовать ее из Python.