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