在《 IronPython in Action》一书中，作者指出，与CPython不同，IronPython受益于JIT和框架本身中的某些优化，CPython无法利用这些优化。因此，IronPython可能比CPython更快，尤其是在多线程方案中。
IronScheme会从这种优化中受益吗？它是解释器(不是编译器)，并且是解释器，因为这是Lisp的本质，必须对其进行解释以提供类似Lisp的灵活性？如果是解释器，它是否还能从抖动优化中受益？
最佳答案
像IronPython(也是我基于IronScheme的DLR的第一个)一样，IronScheme一直编译到IL级别。
此外，IronScheme中没有解释的部分(除非您将其称为运行时符号查找)，因为由于不被使用并减少了代码占用，我已经从我的DLR的“分支”中剔除了所有这些内容(我估计我只使用了大约25％的DLR，其余的则以Python为中心)。
若要查看生成了什么IL，可以查看Reflector .NET中的ironscheme.boot.dll程序集(最好使用IL模式，因为C#往往会进行奇怪的重组，并且在某些情况下完全是错误的)。整个程序集由IronScheme编译。要查看运行时生成的代码要复杂得多。
如前所述，这确实具有JIT的所有优势，并且我在DLR上进行的优化更加以方案为中心，因此它的执行速度通常比我上次测试时的IronPython快(至少可以追溯18个月了，我意识到自那时以来，IronPython有了很多改进，但是IronScheme的速度要快一些，即使使用更像Python的“Scheme”甚至是球类游戏也是如此。
此外，我已经尝试使用尽可能多的.NET框架作为IronScheme的基础，并简化互操作性。诸如vectors，byte-vectors，binary-ports和hash-tables之类的东西都是基于我们都知道并使用的普通.NET类。 object[]，byte[]，Stream和Hashtable，仅举几例。
关于.net - IronScheme被解释或编译了吗？它可以从.NET Framework优化中受益吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4148627/