[gclist] ref-counting performance cost

[Jeff Sturm]

Manoj Plakal wrote:
> How memory/allocation-intensive is your Sieve benchmark?

I don't have good numbers showing the bytes allocated, if that's what
you mean.  My impression is that Tcl tends to allocate a large number of
small, short-lived objects.

> It's a pretty small microbenchmark and artificially jacking up
> the number of primes you generate doesn't seem to generate
> meaningful numbers. 16MB seems like a lot of heap for a
> small program like this. Can you try a large Tcl "application"?
> (if such a beast exists)

That's a good idea, if I had a script I thought to be a good candidate
for benchmarking... though there are certainly large Tcl programs, many
also have a Tk user interface.

The benchmark suite from Scriptics consists mostly of one- or
two-liners, unfortunately, so it is probably less realistic than my
Sieve.

Although I did run tests with a 4MB heap, the results were not too
different.  Large heaps seemed to help the collector, to some extent.

> Ref-counting will probably always be slower than periodic tracing
> (even if you do deferred RC), but I was interested to see if
> RC does really have better cache/VM locality in allocation-intensive
> benchmarks where the tracing collector is invoked more
> frequently and possibly pollutes the cache. Also, it would be interesting
> to see if rapid recycling of garbage by RC does help to improve allocation
> speed/locality or decrease total memory usage (even after possibly leaking
> cyclic structures).

I'm interested as well.  I haven't seen anything convincing yet.

Jeff