2007/12/19, Andreas Raab <andreas.raab at gmx.de>:
> 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?

No, there's nothing funny about it.

> You are describing properties that
> apply to NewCompiler just as well if you disable closure compilation

Yes.

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

They why was the closure solution of the new compiler rejected?

> 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?

Seaside used to send #fixTemps to every block (!)  now it has a more
sophisticated hack: #fixCallbackTemps (that's right a web frameworks
includes hacks to work around block bugs). That works in most
situations. Problems with blocks are rare, however when they happen
you spend a lot of time figuring out what went wrong. With time you
get a certain feeling of what constructs trigger block bugs and try to
avoid them.

Cheers
Philippe