Where to next with Exupery?

Daniel Vainsencher danielv at techunix.technion.ac.il
Sun May 15 15:42:30 UTC 2005

Colin Putney wrote:
> Well, that's kind of difficult. Any code that's really important has  
> already been optimized so that it spends most of its time in  
> primitives. Ultimately, when Exupery is more mature, we'll want to  
> start removing those primitives. In the meantime though, I suspect  the 
> most fertile ground will be stuff that's a little more  peripheral. 
> Perhaps Ogg decoding might be an interesting real-world  application 
> that could benefit from a speed up?
> Colin

Well, I'm not sure. I, at least, often stop optimizing when it becomes a 
pain (no specific method exists in which a global >10% gain would be 

And AFAIU, people usually don't write primitives to deal with recursive 
data structures. Which suggests some guesses at good benchmarks:
1. Squeak stock compiler, compile enough code for it to take a second. 
Improving this affects all loading of new code to the system, which 
would be generally useful.
2. RB parsing and related stuff - would make common moves in programming 
3. Go to some specific Morphic world, and invalidate the whole screen - 
if improved, it would make Squeak more responsive.

And so forth.

TimeProfileBrowser onBlock: [Compiler recompileAllFrom: 'Z']
Illustrates the first, taking 2 seconds, and spending only 5 seconds in 
primitives (at least according to the profiler).

In another direction, have you looked at pystone? being able to say 'x.y 
times the speed of python' would be a relevant thing to say to various 


More information about the Squeak-dev mailing list