MC in basic
andreas.raab at gmx.de
Tue Dec 14 08:20:07 UTC 2004
> The new compiler sounds like a step forward by many measures. The
> performance issue needs to be quantified more. When you say it is slower,
> is it 5% slower? That would be tolerable. If it is 20% slower it might
> not be tolerable.
Running a quick benchmark "[Object compileAll] timeRun" gives:
Old compiler: 1794 1749 1723
New compiler: 4417 4384 4423
So it's about a factor of 2.5 where this might be a little skewed since I
just loaded the closure compiler (which is a little more complex than the
non-closure compiling version) and switched between the two. Hm... this is
significantly more than I expected... and if we actually cut out the time it
takes for retrieving the source code by, e.g., doing:
code := Object selectors asArray
collect:[:sel| Object sourceCodeAt: sel].
compiler := Object compilerClass.
We're almost precisely at a factor of 3 or so (spending ~50% of the time in
> If it breaks eToys, I would think you will need to get
> an estimate from them for what is required to deal with this.
Well, the real issue which I'd like to see fixed is error reporting. I have
found that SmaCC parsers are notoriously bad at it - except from "token not
expected" it doesn't tell you anything about what is wrong (and it doesn't
even tell you the token - so if you don't know how the next characters
compose you are at a total loss). For example, consider the following
a := . Token not expected Expression expected
3 foo: +5 Token not expected Argument expected
[:foo ^3+4] Token not expected Vertical bar expected
[^42 Token not expected Period or right bracket expected
For a newbie this is deeply problematic. It's hard enough to get this stuff
right even if the compiler tells you what it expects - but if you only know
that there is "something wrong here" (perhaps a missing \item? ;-))) it's
almost impossible to find out.
More information about the Squeak-dev