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.

[*] These additional GC's occur because of root table overflows, with
RootTableOverflow.cs, they become about 1/4 second total.

I typically run with:
  Smalltalk vmParameterAt: 5 put: 400000.
  Smalltalk vmParameterAt: 6 put: 12000.

which gives me <100ms incrgc latency. But, given average object size, its
about 10mb/100k objects, so you'll want to run with 40mb free space to
exploit those parameters, more memmory for higher numbers.

Note that SystemDictionary>>setGCParameters resets these values to the
default ones on each restart. You will have to change them there.

-- 

Anyways, a root table overflow is bad. You consume one root table entry
for each 'old' object that is made to point to a some new object. After
2500 entries, you are forced to take a fullGC. An incremental GC does
*not* reset this table. Only a tenure or fullGC does.

You'll typically see this in any routine that holds lots of data, or adds
data incrementally to a large dbase. FTI, for examples, sees them
constantly. The slang-to-C translater sees them constantly. I suspect that
the recent 'Challenge' is likewise experiencing many of them..

Use:   Smalltalk vmParameterAt: 21
to see how many entries have been used.

Use:   Smalltalk vmParameterAt: 22
to see how many times you've overflowed so far.

Basically, that first number is how full the table is, and hte
second number is the number of overflows (fullGC's that could be avoided.)

Until the patch goes in, you can manually fake it by checking if the root
table is near to full (first line), and forcing a tenure.  That saves you
from the fullGC.

----
SystemDictionary>>tenure
        "Incrementally collect all objects and tenure. This is useful
after allocating a large array or after making a large array point to a
new object."
     |oldtenure|
     oldtenure _ self vmParameterAt: 6.
        self vmParameterAt: 6 put: 0.
        self garbageCollectMost.
        self vmParameterAt: 6 put: oldtenure.
----
SystemDictionary>>tenure is part of the FTI engines.

Scott