3 ms·

Reference counting has upsides and downsides. If you look at the lengths that some Java based projects like Spark have to go to in order tame the GC, then you h

Reference counting has upsides and downsides. If you look at the lengths that some Java based projects like Spark have to go to in order tame the GC, then you have to question whether tracing GC is the right choice in the age of hundereds of GBs of memory. On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. Swift's own collection interface changed massively between 2.x and 3 and I believe the main reason for the redesign was that the old design required too much reference counting. (I'm not completely sure this is an accurate reflection of their thinking though)

zzzcpan 10y ago
> On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. This is very wrong on both points. Reference counting has a lot less mental burden compared to GC, because it's predictable. You can rely on destructors to actually work and be useful. For example, you don't have to keep track of whether you closed your file descriptor or not, but in GCd languages you have to do that manually, sometimes even with the same reference counting, but hand-written and explicit. Reference counting is also very fast, with the exception of concurrent decades old implementations, that are irrelevant today.
- fauigerzigerk 10y ago
  I don't disagree on the benefits of RAII at all. I love it. It's a much cleaner and more general resource management idea than a tracing GC. But incrementing/decrementing an atomic value in a tight loop apparently creates a performance problem that is severe enough for the Swift team to redesign their API. That wasn't decades ago: "Code that handles indices has to perform atomic reference counting, which has significant overhead and can prevent the optimizer from making other improvements." https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md https://github.com/apple/swift-evolution/blob/master/proposa...

zzzcpan 10y ago

> On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. This is very wrong on both points. Reference counting has a lot less mental burden compared to GC, because it's predictable. You can rely on destructors to actually work and be useful. For example, you don't have to keep track of whether you closed your file descriptor or not, but in GCd languages you have to do that manually, sometimes even with the same reference counting, but hand-written and explicit. Reference counting is also very fast, with the exception of concurrent decades old implementations, that are irrelevant today.

fauigerzigerk 10y ago
I don't disagree on the benefits of RAII at all. I love it. It's a much cleaner and more general resource management idea than a tracing GC. But incrementing/decrementing an atomic value in a tight loop apparently creates a performance problem that is severe enough for the Swift team to redesign their API. That wasn't decades ago: "Code that handles indices has to perform atomic reference counting, which has significant overhead and can prevent the optimizer from making other improvements." https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md https://github.com/apple/swift-evolution/blob/master/proposa...