[gclist] ref-counting performance cost
Fri, 15 Sep 2000 02:30:07 -0400
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
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.