Daniel Vainsencher writes:
 > Dean_Swan at Mitel.COM wrote:
 > > My first concern is performance.  Since Traits carry no state, they will 
 > > need to use accessor methods and message sends are clearly much slower 
 > > than direct instance variable access.
 > This is currently true. I wouldn't worry about this too much for the 
 > following reasons:
 > 1. We have Bryce on our side! the overhead of self sent accessors shall 
 > soon be reduced to a painful, but fading memory (half kidding, don't 
 > think he ever promised that, but the essence is true)

I'm planning on leaving self send specific optimisations for a while.
It seems sensible to put send improvement efforts into places that
will speed up all sends not just self sends. Besides, if I optimised
self sends then I'd need to find another send benchmark that measured
non-self sends. ;-)

Exupery is currently only twice as fast as the interpreter for sends.
There is plenty of room for improvement both by improving the general
case code and by adding inlining to really optimise frequent sends.

For compiled code, there's probably a space savings by inlining self
sends. Many methods are very small and the compiled send code is
large. For normal sends Exupery always needs to generate a full send
sequence just in case the object isn't of the expected type.

If people feel like putting energy into making Squeak a lot faster
then I've just started stress testing Exupery. Once the stress test
stops crashing, some beta testers would help. The main problem is
figuring out what the minimum amount needed to make Exupery practical
is. After getting to that minimum there's plenty of exciting things
still to do. The stress test involves compiling methods from every
test class in the system. So writing tests of any part of the system
would help too, especially parts that are slow and should be faster.

Bryce