3 ms·
People tend to think that refcounting must be faster than a tracing GC because you don't have to scan the memory. The second half of the previous sentence is tr
by lokedhs 10y ago
People tend to think that refcounting must be faster than a tracing GC because you don't have to scan the memory. The second half of the previous sentence is true, but what they forget is that refcounting needs to do a lot of things that a GC doesn't have to:
Like you said, need to update the reference every time it's moved.
malloc becomes much slower, compared to a GC language (with a compacting GC) where malloc is effectively just a single add instruction.
free also needs to do a lot of bookkeeping while the GC language doesn't need to do anything.
Multithreading introduces another set of issues when dealing with refcounting that is not a problem with a GC.
- je42 10y agoMultithreading also introduces issues for GC. It needs to stop all threads. If you look at how much work has been delivered towards the GC's of for example JVM, Go and V8. It is a really tough problem to get right for all application types. Reference counting is very predictable. And if you see a bottle neck you can start fixing it. And with ARC (Swift/ObjC) you get even compiler support to optimize all ref counting administration. Further malloc doesn't have anything to do with ref counting as ref counting sits on top if it. Further, GC languages also need to do book keeping: Generations and Compaction.
- lokedhs 10y agoThat is true, but only during GC itself. Refcounting causes these issues every time the reference is copied. For malloc, the benefit with a compacting GC is that the free memory will always be in a contiguous segment. Therefore, a malloc operating is similar to a stack allocation in that all you need to do is to move a single pointer. Without a compacting GC, you need to search a tree whenever you want to allocate memory.