Is IronScheme interpreted or compiled? Does it benefit from .NET Framework optimizations?

In the book "IronPython in Action," the author states that IronPython, unlike CPython, benefits from certain optimizations, both in the JIT and in the framework itself, that CPython cannot take advantage of. Consequently, IronPython is potentially faster than CPython is, especially for multithreading scenarios.

Does IronScheme benefit from such optimizations? Is it an interpreter (not a compiler), and is it an interpreter because that's the nature of Lisp, that it must be interpreted to provide the Lisp-like flexibility? If it is an interpreter, can it still benefit from optimizati开发者_如何学编程ons in the jitter?

Like IronPython (well the initial one with the DLR that I based IronScheme on), IronScheme is compiled all the way down to IL level.

Furthermore, there are no interpreted parts in IronScheme (unless you call runtime symbol lookup that), as I have pretty much ripped out all of that from my 'branch' of the DLR, due to not being used and reducing the code footprint (I estimated I only used about 25% of the DLR, where the rest was rather Python-centric).

To see what IL gets generated, you can look at the ironscheme.boot.dll assembly in Reflector .NET (using IL mode preferably, as C# tends to be restructured weirdly and just plain wrong in a few cases). This entire assembly is compiled by IronScheme. To see runtime generated code is a lot more trickier.

As said, this does have all the benefits of JIT, and with the optimizations I made on the DLR to be more Scheme-centric, it generally performed faster than IronPython when I last tested it (a good 18 months back at least, I realize IronPython has had quite a few improvements since then, but IronScheme was a few factors faster, even using Scheme that 'felt' more like Python to even the ball game).

Furthermore, I have attempted to utilize as much of the .NET framework as a foundation for IronScheme, and to make interoperability easier. Things like vectors, byte-vectors, binary-ports and hash-tables are based on the normal .NET classes we all know and use; object[], byte[], Stream and Hashtable respectively, to name a few.