vice. 
> Seems to me it 
> would be better to write benchmarks that run for an amount of time that is
> sufficient to ensure that the overhead of GC is consistent between runs of
> the benchmark. 
The problem is that, in real programs, the code snippet will not be the only 
part of the code allocating objects. When the GC runs, you pay for *all* the 
objects present in the system. Measuring the time the GC takes in a 
controlled situation like a benchmark will not give you any information on 
how much impact your code will have w.r.t. GC in a real program.

> For example, don't write a benchmark that takes 0.001 
> seconds. Write one that takes 30 seconds, or whatever. I'm not experienced
> enough with ruby yet, to know what a sensible duration is.
The problem is not the duration, but the amount of objects created. 
IMO, if you're interested in benchmarking GC effects, benchmark your code in 
both time and object allocation. You'll see the kind of tradeoff that one 
solution has w.r.t. another. (ok: it runs 10 times faster but allocates a lot 
of objects)
-- 
Sylvain