Hi Klaus,

Klaus D. Witzel wrote:
> Hi Martin,
> 
> on Wed, 08 Oct 2008 13:55:19 +0200, you wrote:
> 
> 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
> file.

It'd be great, if you'd do that, please!

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

The performance is exactly what I want to find out. I suppose the impact
of inlining such often used method should be significant but I am not
sure, whether this is true.

However, I don't think that it is a good way of programming that Squeak
relies on this compiler behavior in the places you mentioned. I'm pretty
sure it could be done without this hidden knowledge.

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

AFAIK, that is not a real problem, because BlockContext has the #restart
primitive, which is used by #whileTrue: so that it is not recursive but
simply restarts itself after every loop step.

Regards,
Martin