Den tors 3 dec. 2020 20:58Pascal Costanza <p...@p-cos.net> skrev: > > We evaluated Go and Java for their concurrent, parallel GCs, and C++ for > its reference counting. Interestingly, reference counting is often > described as more efficient than GC, but in our case that’s not true: > Because there is a huge object graph at some stage that needs to be > deallocated, reference counting incurs more or less the same pause that a > non-concurrent GC does. That’s why we don’t expect Rust to fare better here > either.
I'm surprised that you seem to acknowledge the myth that refcounting is somehow more efficient in any way compared to a good GC. Refcounting suffers from a worst-of-both-worlds situation where both allocations and release operations are potentially slow. Allocations need to scan the allocation tree for free memory, and upon release it has to again search the tree to determine where to record it. And that's not even mentioning the overhead during pointer handoff. A GC language by contrast can optimise allocations down to a single instruction, zero instructions for release and no overhead for pointer transfer. In practice, when comparing heap memory allocation between Java and C++ the former readily beats the latter. C++ code may still be faster due to the fact that it can often avoid heap allocations altogether by storing things on the stack. C++ developers also go to great length to avoid using reference counting as well.
