Hi bryce

How would you see the integration of your work with the rest?
Especially the VM maker guys.

Stef


>>> 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
>
>