Dan Ingalls writes:
Mainly I just like to think about this stuff, and it occurred to me that, if someone were looking for a fun experiment or two, it might turn out to have some practical value. I haven't looked at Exupery to know whether these things are already being done, or whether they might fit well with the other techniques there, but I'm sure Bryce could say right off the bat.
Exupery currently creates contexts using the same code as the interpreter does. It calls a C/Slang helper function to set up the new context.
Exupery is about 2.5 times faster than the interpreter for sends which indicates that most of the time is spent figuring out what method is should be executed rather than in creating the context. The speed improvement comes from using polymorphic inline caches which make sends to compiled code from compiled code dispatch very quickly. I'd guess that by tuning the current system and producing custom machine code for the common case where the new context is recycled it would double send performance to about 5 times faster than the interpreter.
My plan current to introduce dynamic method inlining based heavily on Urs Holzle's Self work to Exupery after finishing a 1.0. That will completely remove the context creation costs from the most frequently used sends. Dynamic method inlining has the advantage that it can eliminate the sends from #do: loops as well as from leaf methods.
However, for Exupery, finishing 1.0 is much more important than adding dynamic method inlining. A mere 2.5 times gain in send performance is enough to provide a practical speed improvement. For now my time is better spent first debugging compiled blocks then fixing minor issues that limit Exupery's current usefulness.
Bryce