我做了一些实验，IronPython的2.6.1和clr.CompileModules功能来编译我的大脚本到程序集。测试表明，良好的冷启动性能性能方面的改进，但在某些情况下，导入编译的模块实际上比执行该重新presents我的code。在某些情况下，一个大的字符串比较慢。

I am doing some experiments with IronPython 2.6.1 and the clr.CompileModules function to compile my large scripts into assemblies. Testing has shown good cold start performance performance improvements but in some cases importing the compiled module is actually slower than executing a large string that represents my code in some cases.

我的问题是，如果我使用像

My question is, if i use something like

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

或 ImportModule 功能，即使我得到一个新的ScriptSCope回做的DLR缓存的进口在其他ScriptScopes做？因此，如果模块1和模块10导入同一类型，我只需要表现打一次？

or the ImportModule function, even though I get a new ScriptSCope back does the DLR cache the imports made in other ScriptScopes? So if module 1 and module 10 import the same type, I only take the performance hit once?

时使用 clr.CompileModules preferable了 scope.Compile（）？我的理解是，如果我不希望管理额外的组件，只愿意支付编译成本，一旦飞编译是非常有用的。

Is using clr.CompileModules preferable over scope.Compile()? My understanding is the on the fly compile is useful if I don’t want to manage extra assemblies and only want to pay the compile cost once.

推荐答案

在DLR不会缓存的进口，而是IronPython的一样。

The DLR doesn't cache the imports but IronPython does.

我觉得你的理解是正确的 - clr.CompileModules通常是一个启动利好。您还可以ngen'ing的组件结合起来，你就会有更好的启动PERF。如果你不这样做，就那么这可能是你所看到的表现更差，有时的原因 - 我们可以通过跨$ P $编译code时，首先pting它避免了JIT，但如果你编译我们总是需要JIT 。编译+ NGEN是两全其美不是需要来设置所有这一切了其他的。

I think your understanding is correct - clr.CompileModules is usually good for a startup benefit. You can also combine it with ngen'ing the assemblies and you'll have even better startup perf. If you aren't doing that already then that's probably the reason you are seeing worse performance sometimes - we can avoid the JIT when compiling your code by interpreting it first, but if you compile we always need to JIT. Compiling + ngen is the best of both worlds other than needing to set all of that up.