IronScheme是解释还是编译？它是否受益于.NET Framework优化？

Question

在"IronPython in Action"一书中,作者指出,与CPython不同,IronPython受益于CPython无法利用的JIT和框架本身的某些优化.因此,IronPython可能比CPython更快,特别是对于多线程场景.

IronScheme是否会受益于此类优化？它是一个解释器(不是编译器),它是一个解释器,因为这是Lisp的本质,它必须被解释为提供类似Lisp的灵活性？如果它是一个解释器,它仍然可以从抖动优化中受益吗？

Answer 1

与 IronPython（以及我基于 IronScheme 的 DLR 的第一个 Python）一样，IronScheme 一直编译到 IL 级别。

此外，IronScheme 中没有解释部分（除非您调用运行时符号查找），因为我几乎从 DLR 的“分支”中删除了所有这些部分，因为没有使用并减少了代码占用空间（我据估计，我只使用了大约 25% 的 DLR，其余部分则以 Python 为中心）。

要查看生成的 IL 内容，您可以查看ironscheme.boot.dllReflector .NET 中的程序集（最好使用 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分别仅举几例。