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