> From:  Stephen Pair <stephen at p...>
>  I wonder how this will translate to real world performance? 5%
>  improvement? 10%? Since real code doesn't allocate a bunch of objects
>  in a tight loop like this, I imagine that the % of total cycles spent  
> in
>  allocation must be lower than the 20% in this test case. It would be
>  nice to have some real world benchmarks to compare...building the
>  interpreter is nice, but how about picking a decent sized package and
>  installing it in the image (from disk)? Since, people do tend to do
>  that quite a lot.

If I look bounce atoms, 100, with higher performance I see these  
overall CPU usage numbers
52% interpreter
8.2% related to mac screen updating
5.5% for copyLoopNoSource
4.28% to instantiate (makepoint, pushfloat, allocate/recycle context,  
BlockCopy)
2.8 mark/trace
... etc

Tuning with better code, plus no-fill takes the 4.28% to 2.96% So it's  
1.5% in this example.

I've also done a test allocating 50 ByteArrays in a loop and see a 10%  
faster allocation rate, with the
allocation C routine running at least 30% faster.

This testing still is doing the hash because I wasn't sure how to  
implement the change.  But I see
Lex in message http://groups.yahoo.com/group/squeak/message/65587 has  
an answer for me.

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===