Hi Klaus,

Klaus D. Witzel 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!
Thanks alot.

>>
>> The performance is exactly what I want to find out.
> 
> I compensate by running my notebook's CPU at the higher clock rate, but
> in general Squeak is still responsive (modulo the known CPU hogs like to
> many SystemWindows etc).

First tests using your changeset within the tinyBenchmarks resulted in a
80-85 percent perfomance lose. That says something.... :)

>> 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.
> 
> Yes, I thought about that too. Perhaps in form of a primitive for each
> of the inlineable messages, similiar to the special selectors, which
> might fall through as usual. This way the compiler+decompiler wouldn't
> need to know about "macros" (the term used in the current inlining
> implementation).
You seem to talk about the compiler implementation. That's another
story. I would want that a) the source of those macro-methods would work
without inlining at all, like #ifFalse: and #ifTrue: but not #whileTrue:
(see below) and b) every other code like BlockContext>>#ensure: (look
for thisContext, as you said) would not make usage of these Compiler
internals...

>>>> 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,
> 
> #restart primitive, in Squeak? which .image distro/version, in 3.6-3.10
> I haven't seen such.
Correct, I intermixed this with some other Smalltalk implementations :).
Although Squeak only has a #restart method for contexts, it does not
have a primitive for that. Nevertheless, #whileTrue: could be
implemented non-recursive this way

BlockContext>>#whileTrue: aBlock
  self value ifFalse: [ ^ nil ].
  aBlock value.
  thisContext restart.

instead of simply defining #whileTrue: through itself by implicitly
using the compiler (as it is in my image).

Best regards,
Martin