Reference count, don't garbage collect
Time to tout my own horn. I made a project comparing different types of garbage collectors (I still prefer the original terminology; both ref-counting and <i>tracing</i> garbage collection collects garbage, so they are both garbage collectors) a few years ago: <a href="https:&#x2F;&#x2F;github.com&#x2F;bjourne&#x2F;c-examples" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bjourne&#x2F;c-examples</a><p>Run .&#x2F;waf configure build &amp;&amp; .&#x2F;build&#x2F;tests&#x2F;collectors&#x2F;collectors and it will spit out benchmark results. On my machine (Phenom II X6 1090), they are as follows:<p><pre><code>    Copying Collector                                8.9
    Reference Counting Collector                    21.9
    Cycle-collecting Reference Counting Collector   28.7
    Mark &amp; Sweep Collector                          10.1
    Mark &amp; Sweep (separate mark bits) Collector      9.6
    Optimized Copying Collector                      9.0
</code></pre>
I.e for total runtime it is not even close; tracing gc smokes ref-counting out of the water. Other metrics such as number of pauses and maximum pause times may still tip the balance in favor of ref-counting, but those are much harder to measure. Though note the abysmal runtime of the cycle-collecting ref-counter. It suggests that cycle collection could introduce the exact same pause times ref-counting was supposed to eliminate. This is because in practice cycles are very difficult to track and collect efficiently.<p>In any case, it clearly is about trade-offs; claiming tracing gc always beats ref-counting gc or vice versa is naive.