On Tuesday, January 29, 2002, at 11:15 PM, Scott A Crosby wrote:
Quick summary: The default paramaters for the GC are a poor choice for RAM-rich modern computers. A 3x performance gain on GC is obtainable, if you're willing to dedicate RAM to squeak. (My desktop has 768, so I think nothing of running with 100-500mb)
The current squeak GC does an incremental collection every 4000 allocations. Although this can lead to sub-ms latency, it is excessive, especially for long running or many GUI applications.
So, running macrobenchmarks, and counting GC time, I get:
22 seconds of GC time. (only GC when you absolutely must, 500mb RAM.) 60 seconds of GC time. (GC every 4000 allocations) +15 additional seconds of fullGC's in either case [*]
A typical run of macrobenchmarks is about 360 seconds on the P2-450.
I'm not sure the threshold is where GC time drops by 2/3, but the fact that it does is an indication that other people can have similar gains. I even see some gain at 50mb and 200kallocs/GC.
Just a thought: since the macro-benchmarks are doing full-GCs between each benchmark (not timed), could it be that the performance improvements are just artifacts of the benchmarking process?
In essence, you're getting a GC that's 'free' between each of the benchmarks. So if you can delay the need for a GC until the end of each benchmark, then you will have 0 GC overhead in the benchmarks, without any accompanying real-world gain.
Marcel
-- Marcel Weiher Metaobject Software Technologies marcel@metaobject.com www.metaobject.com Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.