Re:Functional programming languages should be better at muta...
by kaba0 on Wednesday July 31, 2024 @07:07AM
(#41118075)
So, RC is better than tracing GC, when it’s not used as memory management, and it is special cased everywhere.. got you!
Like, as I explicitly wrote, it is probably the correct choice for low-level languages close to the metal, that want easy compatibility with other languages through FFI. But the method itself has still got a much slower throughput than a tracing GC, when used in a similar manner. Anything else is a useless comparison, like is a bicycle better than a tank.
Re:Functional programming languages should be better at muta...
by devit on Wednesday July 31, 2024 @07:54AM
(#41118378)
> But the method itself has still got a much slower throughput than a tracing GC, when used in a similar manner
That is correct, but the issue is not with reference counting, but rather with having unnecessary extremely frequent RC/GC operations.
Once frequency is reduced to only necessary operations (which could be none at all for many programs), reference counting wins since its cost is proportional to the number of operations, while GC has fixed but large costs.
If you use reference counting properly in a well-designed language then it's obviously better than GC since it's rarely used, fast, simple, local and needs no arbitrary heuristics.
The destructor cascades are only a problem for latency and potential stack overflow and can be solved by having custom destructors for recursive structures that queue nodes for destruction, or using arena allocators if applicable.