> From: "Raab, Andreas" <Andreas.Raab at disney.com>
> Peter,
>
> > As a final ramble in an otherwise rambling e-mail, it's
> > interesting to note the current arguments against Squeak,
> > which are the same ones we saw in 1989 when we started using
> > Smalltalk for building interfaces for GPs to use: it's
> > large and it's slow.  Hopefully the image segments should
> > help to sort out 'large', but I'm not sure what to do about 'slow'. 
> > When we re-coded our terminology engine in C, a 24-hour knowledge 
> > base compile went down to 7 minutes.  Extreme, I know, but can the 
> > interpreted-language and OO communities do anything about this?
>
> I believe we can. Just have a look at what Squeak presents to you  
in this
> area - if you really need high performance you have actually several 
> choices. You can write your stuff in Slang and translate it to C  
afterwards
> (thus allowing you to debug the entire thing right within Squeak)  
or code it
> all in C (the way I did it partly in the 3D renderer) or use some  
existing C
> stuff (through the FFI interface).

Ahh, my cue :-)

Rather than having to actually re-code perfectly fine Smalltalk in C  
or slang, which as far as I understand is in some ways even more  
primitive than C, I'd rather be able to direct the system in  
performing mechanical transformations on the code:

(1)	early-bind calls
(2)	in-line calls
(3)	expand/inline loops
(4)	translate to machine code (in any one of the previous states)
(5)	generate specialized versions of methods in subclasses
	and for specific parameters

None of this is new, and systems like HotSpot even try to apply  
these automatically at run-time.  The huge difference is that  
developers can be much more agressive because they are allowed to  
change the semantics and restrict run-time malleability (which they  
would do anyhow when converting the code the Slang or C).  Also, the  
time frame available for analysis and transformation is more in the  
hours and days instead of milliseconds, because time spent analyzing  
does not count towards the execution time.

> The performance improvements are immense
> (usually in the range of 30-150, depending on what you're doing)  
but your
> example (suggesting a speedup of ~200) is not too far away from  
it. But the
> faremost important thing is that you can actually develop your  
application
> very rapidly and if (and only if) certain parts are too slow you  
can go on
> and improve those. Thus choosing exactly those aspects that need to go 
> faster and don't worry about everything else. After you actually  
understood
> the problem ;-)

Exactly!

Marcel