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 at metaobject.com		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.