Dan Ingalls writes:
Bryce Kampjes bryce@kampjes.demon.co.uk wrote...
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.
I agree that inlining is the ultimate way to go here. You can see lazy activation as a sort of lazy approach to inlining, but inlining is better because it eliminates the lookup and context switch times completely (when possible (which is typically very often)).
Thanks Dan, Inlining is definitely a key optimisation. For Exupery another advantage is that it creates large native methods that have enough code to be able to be classically optimised. Small methods get in the way of many optimisations. Inlining will provide both a great speed improvement and also make later optimisations possible.
The lazy activation approach you describe is orthogonal to inlining. Both ideally would be best. Especially if the lazy context creation is done along the lines Jecel described by moving the context creation code forward to the first send. A truly dynamic approach which lazily creates a context like lazy initialisation risks spending more time evaluating the context creation checks than was spent creating the context.
The idea of cloning contexts is effectively the same as creating custom machine code to generate the context. The advantage of custom machine code is there is no loop overhead and no branch mispredict when exiting the loop.
For the interpreter this may be a decent win. The biggest issue is the speed improvement that Exupery has over the interpreter indicates that most of the time during sends is being spent outside of context creation. But if you're after a 10% gain or you've got an engine with different performance characteristics it could be worth trying.
Bryce