In Go, there's much larger overhead for GC. Russ Cox says in [2] (see link in my first comment above): We used gopprof to study an inefficient Go program and t

In Go, there's much larger overhead for GC. Russ Cox says in [2] (see link in my first comment above): We used gopprof to study an inefficient Go program and then to improve its performance by an order of magnitude and to reduce its memory usage by a factor of six. A subsequent comparison with an equivalently optimized C++ program shows that Go can be competitive with C++ when programmers are careful about how much garbage is generated by inner loops. They got a speedup about order of magnitude by improving memory management in the inner loops. So 10% of time for refcounting isn't that much. 90% of time for GC is much worse. Especially if it is a stop-the-world GC on 12-core server system. One core collects garbage, 11 cores just cool off.