在“IronPython in Action”一书中，作者指出，与 CPython 不同，IronPython 受益于 JIT 和框架本身的某些优化，而 CPython 无法利用这些优化。因此，IronPython 可能比 CPython 更快，尤其是对于多线程场景。
IronScheme 是否受益于此类优化？它是一个解释器（不是编译器）吗？它是一个解释器，因为这是 Lisp 的本质，它必须被解释以提供类似 Lisp 的灵活性？如果是解释器，它还能从抖动中的优化中受益吗？
【问题讨论】：
标签： .net optimization compiler-construction scheme ironscheme
与 IronPython（以及我基于 IronScheme 的第一个具有 DLR 的）一样，IronScheme 一直编译到 IL 级别。
此外，IronScheme 中没有解释部分（除非您调用运行时符号查找），因为我几乎从 DLR 的“分支”中删除了所有这些部分，因为没有使用并减少了代码足迹（我估计我只使用了大约 25% 的 DLR，其余部分则以 Python 为中心）。
要查看生成的 IL，您可以查看 Reflector .NET 中的 ironscheme.boot.dll 程序集（最好使用 IL 模式，因为 C# 往往会被奇怪地重组，并且在某些情况下会出现明显错误）。整个程序集由 IronScheme 编译。查看运行时生成的代码要复杂得多。
如前所述，这确实具有 JIT 的所有优点，并且由于我对 DLR 进行的优化以更加以 Scheme 为中心，所以当我上次测试它时，它通常比 IronPython 执行得更快（至少 18 个月前） ，我意识到 IronPython 从那时起已经有了相当多的改进，但 IronScheme 的速度要快一些，即使使用“感觉”更像 Python 的 Scheme 甚至是球赛）。
此外，我尝试尽可能多地利用 .NET 框架作为 IronScheme 的基础，并使互操作性更容易。 vectors、byte-vectors、binary-ports 和 hash-tables 之类的东西是基于我们都知道和使用的普通 .NET 类； object[]、byte[]、Stream 和 Hashtable，仅举几例。
【讨论】：