On Mon, 7 Jul 2003 01:32:34 +0200, "Andreas Raab" <andreas.raab at gmx.de> writes:

> So I spend the day fixing this to see what the effect actually is. Like I
> suspected, the change is significant. For tinyBenchmarks it gets us:
> 
> 	'112974404 bytecodes/sec; 3236713 sends/sec' "before"
> 	'123195380 bytecodes/sec; 3433110 sends/sec' "after"
> 
> which makes for +8% in bytecode and +6% in send speed without actually
> changing any real code. Even macroBenchmarks agree on 4-6% improvements in
> real-life code which is pretty significant, considering that much of the
> code is in primitives:

I just checked to see if my new method cache from about a year&half
ago went in. It looks not. If I remember right it was a 5-15% gain on
microbenchmarks at the time. You might want to reincarnate it. I also
had another change that was worth 5% by not having squeak read the
clock 40,000 times a second. I think you had a proposed patch for
this? Did that go in?

I don't remember all of the details, but if I remember right, when I
combined both the core interpreter changes and some string
enhancements, I found my interpreter was 30-50% faster than the stock
one for macrobenchmarks.

As is before, the current method cache is ALWAYS, at most 2/3
occupied.  It also pessimizes the branch prediction (What focussed my
effort was finding out that a single instruction in the code accounted
for a huge amount of the tuntime.

Scott