3 ms·

Reference counting works just fine in Python and C++. If reference counter is thread-local (i.e. its increment/decrement is not done with InterlockedIncrement/

• pcwalton 15y ago
  You'd be surprised how much overhead our reference counting has. 10% of the time of rustc, last I measured, was spent adjusting reference counts.
  • mkup 15y ago
    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.
    • enneff 15y ago
      Your conclusion is flawed. We got an order of magnitude improvement by making a naively-constructed program efficient, and it was easy. That's hardly an indictment of Go's garbage collector. Also, the Go GC is a parallel GC which will use all cores during collection.