Reference Counting vs GC
The cluster centers on debates about whether reference counting constitutes garbage collection, its performance costs like overhead from increments/decrements and handling cycles, and comparisons to tracing GC in languages such as Rust, Swift, and Python.
Activity Over Time
Top Contributors
Keywords
Sample Comments
reference counting is not necessarily faster.
Reference counting is much slower than 'garbage collection'.
That reference counting is done at runtime. It’s a runtime garbage collector. It’s different than a generational GC, but it’s GC. Those cycles to increment and decrement a counter attached to every object at ever touch aren’t free. All the downvotes in the world won’t make that free.
Reference counting is GC. Simple, but GC.
Does ref-counting count as garbage collection?
Reference counting is not better, it's a poor man's GC. Reference counting means: 1) instruction pollution from all the refcount updates and their synchronization 2) circular references, ie memory leaks 3) too much time spent freeing memory (whereas a generational GC spends time on live objects only) 4) memory fragmentation and hence slow allocation (whereas in a normal GC allocation is just O(1)
Reference counting is never fast. Even on a single core.
Why don't you use reference counting GC?
Reference counting is hardly modern, and is a GC algorithm.
Ah so you're defining reference-counting as garbage collection?