在“IronPython in Action”一书中，作者指出，与CPython不同，IronPython受益于CPython无法利用的JIT和框架本身的某些优化。因此，IronPython可能比CPython更快，特别是对于多线程场景。
IronScheme是否会受益于此类优化？它是一个解释器（不是编译器），它是一个解释器，因为这是Lisp的本质，它必须被解释为提供类似Lisp的灵活性？如果它是一个解释器，它仍然可以从抖动优化中受益吗？
答案 0 :(得分：3)
就像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甚至是球赛的方案。）
此外，我尝试使用尽可能多的.NET框架作为IronScheme的基础，并使互操作性更容易。 vectors，byte-vectors，binary-ports和hash-tables之类的内容基于我们都知道和使用的普通.NET类;仅举object[]，byte[]，Stream和Hashtable，仅举几例。