[squeak-dev] Re: Inline compiler optimizations

Klaus D. Witzel klaus.witzel at cobss.com
Wed Oct 8 12:33:07 UTC 2008

Hi Martin,

on Wed, 08 Oct 2008 13:55:19 +0200, you wrote:

> Hi,
> does anyone already know, what the impact the inline compiler
> optimizations like avoiding #ifTrue: or #to:do sends has on the VM
> performance? Or, where could I disable then in order to measure it  
> myself?

Funny :) in the past 6 months (or so), other Squeakers wanted to know  
about disabling the inlineing, albeit for different reasons.

I have created a patch for them with which inline-optimization can be  
toggled per method (using some pragma), send email if you want that .cs  

When disabling all inlining, the .image only stays usable if special care  
is taken in advance for constructs like [thisContext] and #some/nextObject  
enumerations (especially those during #startUp); besides of that the  
formerly inlined methods perform very well at their message level (and you  
can even see e.g. lines with True>>#ifTrue: in the debugger ;)

> btw. some methods, especially in the exception handling code, use the
> knowledge about this implicit optimizations, for example when they use
> thisContext in an #ifTrue: or #whileTrue: block, which does not return
> the BlockContext in that cases... :)

I've not checked exceptions in particular. Also, I always inline #while*'s  
because one can run out of memory very soon if they would be performed in  
their recursive fashion ;)


More information about the Squeak-dev mailing list