Andreas Raab writes:
 > To be honest - I don't expect this to make any significant difference. 
 > Simply because allocation speed is only a fraction of the cost of even a 
 > loop like:
 > 	1 to: 1000000 do:[:i| 0 at 0]
 > If you actually measure that you'll find that about half of the time is 
 > spent in GC and that's for the *optimal* (and completely unrelatistic) 
 > case of zero survivors (meaning GC is a lot faster than usual) and not 
 > even counting the loop overhead. If you actually measure the loop 
 > overhead (which creates no GCs) and subtract that from the tally results 
 > you end up with something that says that more than 80% of the remaining 
 > time (which is due to actual allocation) is spent in garbage
collection.

I get 22% of the time inside the GC with 369ms with the 0 at 0s and 101ms
with the 0 at 0 commented out so on my machine with my VM and current
compile flags so 30% of the object creation overhead is GC and 70% is
allocation. That's running interpreted code. So using my measurements,
I could get realistically get a two to three times gain in compiled
code.

I'm measuring GC time with TimeProfileBrowser. Unless you're measuring
with a more accurate tool then I guess platform matters for relative
times.

It's very possible that GC efficiency depends on CPU/memory bandwidth.
My current machine has a 10% faster clock and 8 times the memory
bandwidth of my old machine.

Modifying the GC to use a copying collector for new space will speed
up GC performance noticably.

Thanks for the interesting emails. And yes, this is enough theory
without proper profiling.

Bryce