Зачем компилировать код Python?
Зачем вам компилировать скрипт Python? Вы можете запускать их прямо из файла .py, и он отлично работает, так есть ли преимущество в производительности или что-то в этом роде?
Я также заметил, что некоторые файлы в моем приложении компилируются в .pyc, а другие нет, почему это?
@PSyLoCKe Вы действительно, действительно не знаете. Байт-код Python действительно удобочитаем, потому что компилятору не нужно скрывать его, чтобы оптимизировать. (Не то чтобы это сильно оптимизирует ...)
Причина, по которой некоторые файлы компилируются автоматически, заключается в том, что они импортируются; например, если вы используете import mylib.py, Python скомпилирует mylib.py, чтобы будущие операторы import выполнялись немного быстрее. Если вы позже измените mylib.py, он будет повторно скомпилирован при следующем импорте (Python использует дату файла, чтобы увидеть, что это произойдет.)
Ответы 10
Конечно, есть разница в производительности при запуске скомпилированного скрипта. Если вы запускаете обычные сценарии .py, машина компилирует их каждый раз при запуске, а это требует времени. На современных машинах это практически незаметно, но по мере роста скрипта это может стать проблемой.
Повышается производительность при запуске скомпилированного python. Однако, когда вы запускаете файл .py как импортированный модуль, python скомпилирует и сохранит его, и пока файл .py не изменяется, он всегда будет использовать скомпилированную версию.
При использовании файла на любом языке с интерполяцией процесс выглядит примерно так:
1. Файл обрабатывается интерпретатором.
2. Файл скомпилирован
3. Выполняется скомпилированный код.
очевидно, что с помощью предварительно скомпилированного кода вы можете исключить шаг 2, это касается python, PHP и других.
Вот интересный пост в блоге, объясняющий различия http://julipedia.blogspot.com/2004/07/compiled-vs-interpreted-languages.html
А вот запись, объясняющая процесс компиляции Python http://effbot.org/zone/python-compile.htm
Да, производительность - это основная и, насколько я знаю, единственная причина.
Если некоторые из ваших файлов не компилируются, возможно, Python не может записывать в файл .pyc, возможно, из-за разрешений на каталог или чего-то еще. Или, возможно, некомпилированные файлы просто никогда не загружаются ... (скрипты / модули компилируются только при первой загрузке)
Он скомпилирован в байт-код, который можно использовать намного, намного быстрее.
Причина, по которой некоторые файлы не компилируются, заключается в том, что основной сценарий, который вы вызываете с python main.py, перекомпилируется каждый раз, когда вы запускаете сценарий. Все импортированные скрипты будут скомпилированы и сохранены на диске.
Важное дополнение от Бен Бланк:
It's worth noting that while running a compiled script has a faster startup time (as it doesn't need to be compiled), it doesn't run any faster.
Стоит отметить, что хотя запуск скомпилированного скрипта имеет более быстрое время запускать (так как его не нужно компилировать), он не быстрее запустить.
Распространенное заблуждение. Спасибо, что поделился.
Помимо того, что файл .pyc не требует компиляции, он почти всегда меньше. Особенно если много комментировать. Один из моих - 28419 как .py, но только 17879 как .pyc, поэтому время загрузки тоже лучше. Наконец, вы можете предварительно скомпилировать скрипты верхнего уровня следующим образом: python -m compileall myscript.py
Есть ли разница в потреблении памяти? Я тестирую Python на встроенных устройствах на базе процессора mips с 64 МБ ОЗУ, поэтому есть ли какие-либо преимущества в использовании памяти при запуске скомпилированной версии скрипта Python?
@valentt: Наверное, нет. Я мало что знаю о внутреннем устройстве Python, но не думаю, что синтаксический анализ байт-кода занимает много памяти в Python. Я не могу придумать что-то, что требует много памяти, чтобы запомнить какое-то состояние.
@BenBlank будет ли разница в скорости выполнения, если вы динамически импортируете модуль, например, в начале функции. Я спрашиваю, потому что, когда у меня был циклический импорт между двумя моделями django в разных приложениях (между ними было много отношений, и у каждого из них были свойства, которые выполняли агрегаты и т.д. на другом), и я не уверен, все ли это скомпилировано и в любом случае загружается в память, или если вызов этой функции действительно займет больше времени с некомпилированным Python.
@semicolon - Python импортирует модули только тогда, когда встречается фактическая строка import, поэтому попадание для компиляции произойдет при первом выполнении функции. Однако это только первый раз после изменения кода импорта; он не перекомпилируется, пока для него существует последняя версия .pyc.
@BenBlank, поэтому в тот момент, когда он встречает его при запуске функции, он создает .pyc и всегда использует его в будущем?
@semicolon - до тех пор, пока файл импорта .py не изменится, да.
IMHO, сначала следует упомянуть Важное дополнение, поскольку первое предложение этого ответа немного вводит в заблуждение
Как уже упоминалось, вы можете повысить производительность, если ваш код Python скомпилирован в байт-код. Обычно этим занимается сам python, только для импортированных скриптов.
Другая причина, по которой вы можете захотеть скомпилировать свой код на Python, может заключаться в защите вашей интеллектуальной собственности от копирования и / или изменения.
Подробнее об этом можно прочитать в Документация Python.
Что касается защиты вашего кода - компиляция не очень поможет. Компиляция обфускации - но кто-то желающий все равно получит ваш код.
@josh, что всегда возможно, если можно получить доступ к памяти или посмотреть инструкции к процессору, имея достаточно времени и желания, чтобы они могли воссоздать ваше приложение.
Согласились, однако, как сказал Unkwntech, это всегда будет возможно, если человек будет достаточно решительным. Но я убежден, что этого будет достаточно в большинстве ситуаций, когда вы обычно просто хотите ограничить людей от «исправления» вашего кода ...
Языки, которые скомпилированы в байт-код, обычно не являются что трудными для обратная компиляция, если вы не предпримете дополнительных шагов для их обфускации - просто компиляции обычно недостаточно.
Файл .pyc - это Python, который уже был скомпилирован в байт-код. Python автоматически запускает файл .pyc, если находит файл с тем же именем, что и вызываемый вами файл .py.
"Введение в Python" говорит это о скомпилированных файлах Python:
A program doesn't run any faster when it is read from a ‘.pyc’ or ‘.pyo’ file than when it is read from a ‘.py’ file; the only thing that's faster about ‘.pyc’ or ‘.pyo’ files is the speed with which they are loaded.
Преимущество запуска файла .pyc заключается в том, что Python не требует дополнительных затрат на его компиляцию перед запуском. Поскольку Python в любом случае компилируется в байтовый код перед запуском файла .py, кроме этого не должно быть никакого улучшения производительности.
Насколько можно улучшить использование скомпилированных файлов .pyc? Это зависит от того, что делает сценарий. Для очень короткого сценария, который просто выводит «Hello World», компиляция может составлять большой процент от общего времени запуска и выполнения. Но стоимость компиляции сценария относительно общего времени выполнения уменьшается для более длительных сценариев.
Сценарий, который вы называете в командной строке, никогда не сохраняется в файл .pyc. Таким образом сохраняются только модули, загруженные этим «основным» скриптом.
Во многих случаях трудно увидеть разницу, но у меня есть конкретный файл python с более чем 300 000 строк. (Это набор математических вычислений, сгенерированных другим сценарием для тестирования). Компиляция занимает 37 секунд, а выполнение - всего 2 секунды.
Новички предполагают, что Python скомпилирован из-за файлов .pyc. Файл .pyc - это скомпилированный байт-код, который затем интерпретируется. Итак, если вы уже запускали свой код Python раньше и у вас есть файл .pyc, он будет работать быстрее во второй раз, так как ему не нужно повторно компилировать байт-код.
компилятор: Компилятор - это фрагмент кода, который переводит язык высокого уровня на машинный язык.
Переводчики: Интерпретаторы также преобразуют язык высокого уровня в машиночитаемые двоичные эквиваленты. Каждый раз, когда интерпретатор получает код языка высокого уровня для выполнения, он преобразует код в промежуточный код перед преобразованием его в машинный код. Каждая часть кода интерпретируется, а затем выполняется отдельно в последовательности, и в части кода обнаруживается ошибка, которая останавливает интерпретацию кода без перевода следующего набора кодов.
Источники:http://www.toptal.com/python/why-are-there-so-many-pythonshttp://www.engineersgarage.com/contribution/difference-between-compiler-and-interpreter
Ваше определение «компилятор» неверно. Компилятор никогда не компилировался в машинный код. Компилятор - это просто переводчик с одного языка на другой. Вот почему мы говорим, что Python «компилирует» в байт-код, Coffeescript «компилирует» в Javascript и так далее, и тому подобное.
Плюсы:
Во-первых: мягкое, устранимое обфускация.
Во-вторых: если в результате компиляции файл будет значительно меньше, время загрузки будет меньше. Хорошо для Интернета.
В-третьих: Python может пропустить этап компиляции. Быстрее при начальной загрузке. Хорошо для процессора и Интернета.
В-четвертых: чем больше вы комментируете, тем меньше будет файл .pyc или .pyo по сравнению с исходным файлом .py.
Пятое: конечный пользователь, имеющий в руках только файл .pyc или .pyo, с гораздо меньшей вероятностью сообщит вам об ошибке, вызванной необратимым изменением, о котором они забыли вам сообщить.
Шестое: если вы нацелены на встроенную систему, получение меньшего размера файл для встраивания может представлять собой значительный плюс, а архитектура стабильна, поэтому недостаток, описанный ниже, не играет роли.
Компиляция верхнего уровня
Полезно знать, что вы можете скомпилировать исходный файл Python верхнего уровня в файл .pyc следующим образом:
python -m py_compile myscript.py
Это удаляет комментарии. Он оставляет docstrings нетронутым. Если вы хотите также избавиться от docstrings (возможно, вы захотите серьезно подумать о том, зачем вы это делаете), то вместо этого скомпилируйте этот способ ...
python -OO -m py_compile myscript.py
... и вы получите файл .pyo вместо файла .pyc; одинаково распространяемый с точки зрения основных функциональных возможностей кода, но меньший по размеру, чем у вырезанного docstrings (и менее понятный для последующего использования, если он изначально имел приличный docstrings). Но обратите внимание на третий недостаток ниже.
Обратите внимание, что python использует дату файла .py, если она присутствует, чтобы решить, должен ли он выполнять файл .py, а не файл .pyc или .pyo - поэтому отредактируйте свой файл .py, и .pyc или .pyo устарели и что угодно выгоды, которые вы получили, теряются. Вам необходимо перекомпилировать его, чтобы снова получить преимущества .pyc или .pyo, какими они могут быть.
Недостатки:
Во-первых: в файлах .pyc и .pyo есть «волшебный cookie», который указывает архитектуру системы, в которой был скомпилирован файл python. Если вы распространите один из этих файлов в среде другого типа, он сломается. Если вы распространяете .pyc или .pyo без связанного .py для перекомпиляции или touch, чтобы он заменял .pyc или .pyo, конечный пользователь также не сможет это исправить.
Во-вторых: если docstrings пропущены с использованием параметра командной строки -OO, как описано выше, никто не сможет получить эту информацию, что может сделать использование кода более трудным (или невозможным).
В-третьих: опция Python -OO также реализует некоторые оптимизации в соответствии с опцией командной строки -O; это может привести к изменениям в работе. Известные оптимизации:
sys.flags.optimize= 1- Операторы
assertпропускаются __debug__= Ложь
В-четвертых: если вы намеренно сделали свой исполняемый файл сценария python с чем-то вроде #!/usr/bin/python в первой строке, это будет удалено в файлах .pyc и .pyo, и эта функциональность будет потеряна.
Пятое: отчасти очевидно, но если вы скомпилируете свой код, это может не только повлиять на его использование, но и вероятность того, что другие будут учиться на вашей работе, уменьшится, часто очень сильно.
Мы используем скомпилированный код для распространения среди пользователей, не имеющих доступа к исходному коду. В основном, чтобы не дать неопытным программистам случайно что-то изменить или исправить ошибки, не сообщив нам об этом.
Что-то не затронутое - это компиляция исходного кода. Например, nuitka переводит код Python в C / C++ и компилирует его в двоичный код, который напрямую запускается на ЦП, вместо байт-кода Python, который выполняется на более медленной виртуальной машине.
Это может привести к значительному ускорению или позволит вам работать с Python, в то время как ваша среда зависит от кода C / C++.
Вы также можете отметить, что, включая более быстрый запуск вашего приложения, вы также получаете защиту, если не можете поделиться своим кодом, если он является корпоративной тайной.