Производительность импорта IronPython с помощью скомпилированного кода - PullRequest
1 голос
/ 09 февраля 2011

Я провожу некоторые эксперименты с IronPython 2.6.1 и функцией clr.CompileModules, чтобы скомпилировать мои большие скрипты в сборки. Тестирование показало хорошие улучшения производительности при холодном запуске, но в некоторых случаях импорт скомпилированного модуля на самом деле медленнее, чем выполнение большой строки, которая представляет мой код в некоторых случаях.

Мой вопрос, если я использую что-то вроде

scope.Engine.Execute(string.Format("from {0} import {0}", theModule), scope);

или ImportModule, даже если я получаю новый ScriptSCope, кеширует ли DLR импорт, выполненный в других ScriptScopes? Так что, если модуль 1 и модуль 10 импортируют один и тот же тип, я беру производительность только один раз?

Является ли использование clr.CompileModules предпочтительнее, чем scope.Compile()? Насколько я понимаю, компиляция на лету полезна, если я не хочу управлять дополнительными сборками и хочу оплатить стоимость компиляции только один раз.

1 Ответ

1 голос
/ 09 февраля 2011

DLR не кэширует импорт, а IronPython делает.

Я думаю, что вы правильно поняли - clr.CompileModules, как правило, полезны для стартапа.Вы также можете комбинировать его с созданием сборок, и у вас будет еще лучшая производительность при запуске.Если вы еще этого не делаете, то, вероятно, по этой причине вы иногда видите худшую производительность - мы можем избежать JIT при компиляции вашего кода, сначала интерпретируя его, но если вы компилируете, нам всегда нужен JIT.Компиляция + ngen - лучшее из обоих миров, за исключением того, что нужно все это настраивать.

...