Philippe Marschall wrote:
>> Concerning speed: When doing an [Object2 compileAll] timeToRun (Object2
>> being the partial copy of class Object that NewCompiler was able to hand
>> me) I ended up with 1444 msecs for Compiler and 4020 msecs for
>> NewCompiler. Unless I'm mistaken this is an improvement over the last
>> version I tried which was roughly 4x slower (this is still 2.8x slower
>> but it's a definitive improvement).
> 
> I wasn't talking about compilation speed. What's really limiting for
> bigger projects is not the speed of the compiler but PackageInfo which
> makes Monticello slow. I was talking about execution speed.

I see. Has anyone measured the performance of the micro and macro 
benchmarks with the entire system compiled for using closures? I'm 
particularly interested in the macro benchmarks.

>>> You should ask Marcus about what the current status exactly is. Or Klaus.
>> It would be a big step if it were possible to recompile Squeak
>> successfully
> 
> The NewCompiler images from Marcus do this since a long time ago. See
> the Recompiler class.

Ah, good.

>> and perhaps even bytecode-identically.
> 
> Nah, NewCompiler in certain circumstances generates marginally more
> efficient bytecode.

This may actually be worthwhile "undoing" simply for being able to 
verify correctness.

>>>> And, do you know of any energy focused on improving the existing alternatives?
>>> What alternatives?
>> The compiler that's actually being used. The one that's 3x faster ;-)
> 
> The one that's causing so much trouble in Seaside? The that gives you
> this cool C++ feeling bugs where you spend two hours trying to find
> out why your block arguments are all messed up and you think you went
> crazy? And then suddenly you add a lot of #fixTemps everywhere until
> it works?

Am I missing a smiley somewhere? You are describing properties that 
apply to NewCompiler just as well if you disable closure compilation and 
there is really no reason whatsoever why a working closure solution 
couldn't be adopted to the current compiler (which would mitigate the 
risk factors of adoption dramatically). Just like I was saying in the 
part you'd snipped away I'd be quite interested in adopting a working 
solution (which doesn't strike me as hard given the simplistic nature of 
the current compiler).

BTW, since you phrase it as such a big deal, is anyone using NewCompiler 
with Seaside? If it is really as problematic as you make it above I'd 
expect to see users of Seaside using it. Do they? If so, what's the 
practical experience?

Cheers,
   - Andreas