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