「IronPython in Action」という本の中で、著者は、IronPython は CPython とは異なり、JIT とフレームワーク自体の両方で、CPython が利用できない特定の最適化の恩恵を受けると述べています。その結果、IronPython は、特にマルチスレッドのシナリオでは、CPython よりも潜在的に高速です。
IronSchemeはそのような最適化の恩恵を受けますか? それはインタープリター (コンパイラーではない) ですか? それは Lisp の性質であり、Lisp のような柔軟性を提供するには解釈する必要があるため、インタープリターですか? インタープリターの場合、ジッターの最適化の恩恵を受けることができますか?
IronPython (IronScheme のベースとなった DLR を備えた初期のもの) と同様に、IronScheme は IL レベルまでコンパイルされています。
さらに、IronScheme には解釈された部分はありません (ランタイム シンボル ルックアップを呼び出さない限り)。これは、使用されず、コードのフットプリントが削減されたため (I私が使用したのは DLR の約 25% だけで、残りは Python 中心でした)。
どの IL が生成されるかを確認するにはironscheme.boot.dll、Reflector .NET でアセンブリを確認できます (C# は奇妙に再構築される傾向があり、場合によっては単純に間違っている傾向があるため、IL モードを使用することをお勧めします)。このアセンブリ全体が IronScheme によってコンパイルされます。実行時に生成されたコードを表示するのは、さらに複雑です。
前述のように、これには JIT のすべての利点があり、DLR で行った最適化により、Scheme 中心になるようにしたため、最後にテストしたときは通常、IronPython よりも高速に実行されました (少なくとも 18 か月前の良い結果であることがわかりました)。それ以来、IronPython にはかなりの改良が加えられましたが、IronScheme は、球技でさえも Python のように「感じられる」Scheme を使用しても、数倍高速でした)。
さらに、IronScheme の基盤として .NET フレームワークをできるだけ活用し、相互運用性を容易にすることを試みました。、、、などはvectors、byte-vectors私たちがよく知っていて使用している通常の .NET クラスに基づいています。、、およびそれぞれいくつか例を挙げます。binary-portshash-tablesobject[]byte[]StreamHashtable