Импорт модуля в IronPython 2.7.1 очень медленный - PullRequest
Новая
       15

Импорт модуля в IronPython 2.7.1 очень медленный

1 голос
/ 17 февраля 2012

(первый вопрос по StackOverflow, рад быть там :))

Я использую IronPython 2.7.1 и C # .net 4.0.

Я использую C # для запуска скрипта на python. У меня есть около 20 персональных модулей, которые импортируются много раз. Например:

Если у меня есть module1.py, module2.py, module3.py, module4.py и main_script.py.

main_script.py импортирует module1 и module2

Модуль1 и модуль2 импортируют модуль3.

module1 и module3 импорт module4

и т.д.

Модули могут содержать большое количество строк кода.

Я вижу, что когда я выполняю свой main_script.py, для импорта модулей требуется около 4-5 секунд.

Я пытался использовать pyc.py для компиляции всех моих модулей в dll, а затем использовал на ней ngen, но я не увидел различий при добавлении этой dll с помощью myEngine.Runtime.LoadAssembly ().

Затем я хотел использовать py_compile.py для получения файлов pyc, но, похоже, он не работает, так как тип IronPython.Runtime.FunctionCode не поддерживается в классе IronPython.Modules.MarshalWriter (функция WriteObject (object o). ( При попытке компиляции я получил исключение "unmarshallable object".

Я не очень хорошо знаком ни с Python, ни с IronPython, и, возможно, я не понимал всех тонкостей языка (я так думаю, на самом деле). Я искал в сети решение, но, похоже, я застрял прямо сейчас.

Есть идеи по улучшению производительности импорта?

1 Ответ

2 голосов
/ 17 февраля 2012

Импорт IronPython 2.7.1 занимает 4-5 секунд для импорта, особенно для больших модулей.Я бы улучшил его pyc.py, но я также думаю, что он не так полезен, как раньше - импорт IronPython намного быстрее, чем раньше, поэтому pyc.py менее полезен.

Дело в том, что IronPython делает гораздо больше, чем Python, когда импортирует модуль [1].Python должен проанализировать его и создать байт-код, который он затем выполняет.IronPython должен создавать деревья DLR, которые затем преобразуются в инструкции интерпретатора - и, возможно, также IL, если они превышают предел компиляции, что означает запуск .NET JIT для создания машинного кода.

Вся эта работа теряется, еслизапуск сценария занимает всего несколько секунд;IronPython лучше для длительных процессов.Тем не менее, короткий сценарий Python является чрезвычайно распространенным, а IronPython крайне плох для таких сценариев.

Есть два способа решения этой проблемы, один из которых вы упомянули.Ведется работа по поддержке стандартных файлов .pyc с интерпретатором, оптимизированным для времени запуска, но не для пропускной способности - выиграют короткие сценарии, но пострадает долго работающий код.Во-вторых, портирование IronPython на мобильные платформы требует отключения динамической генерации кода, поэтому очень важно сделать интерпретатор DLR быстрым;эта работа также ускорит запуск некомпилированного кода.

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

[1] Процесс импорта Python настолько быстр, что статистические вызовы для поиска файла намного большечем время, чтобы разобрать и скомпилировать его.

...