Hacker News Reader

Comment by voyou | Hacker News Reader

RAII is great, and should be used where appropriate. I'm not sure what it has to do with reference counting, though. Reference counting is just a particularly slow and unreliable form of garbage collection; I don't see why you would ever prefer it to a proper garbage collector.

View on HN

Tracing and Refcounting are each others duals,

www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

Because it is deterministic? (i'm just guessing that what you call "proper" garbage collector is non-deterministic).

Furthermore, the only "advantage" I see in garbage collectors is that they can deal with cycles.

I say "advantage" because i'm of the strong opinion that having a cycle in your code is a software design error.

Say you are implementing a self-tracking objects model for data management. How do you fix the reversal of control required to manage that? Specifically you need to go from the representative object to the controller to store the fact that you changed.

Weak ptr/reference.

Also I would say that it's very uncommon to do/need something like this so it shouldn't be cited as an reason for cycles to be generally handled.

I have done weak pointer logic, it is not pretty.

Could you elaborate?

Entity Framework, when you modify an object it stores in a central location what the change was to be written out to a location latter.

It is performance wise infeasible to avoid that circular reference because it is very easy to pull back a lot of data from entity framework and change none of it.

Classic RAII in C++ is a limited form of ref-counting (only one ref).

I have to disagree with your second statement, ref-counting is extremely fast. If you consider it a GC then it's the fastest GC. It's also deterministic and does not pause.

> If you consider it a GC then it's the fastest GC. It's also deterministic and does not pause.

No, it's not, not unless you use a lot of cleverness. "We find that an existing modern implementation of reference counting has an average 30% overhead compared to tracing…" (They did perform a lot of optimizations to get it up to speed with tracing garbage collection... however, these are far beyond what shared_ptr does.)

http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2...

I'm a bit skeptical of the results of that paper without the seeing the source code and in what contexts they are performing the comparison. One can always find situations where one scheme is faster than the other but I'm not totally sure if micro benchmarks are representative of the real world. In long-lived servers, ref-counting can be preferable because it avoids random pauses. Maybe it's a latency vs throughput performance dichotomy. But yeah, thanks for posting that.

Reference counting doubles the number of memory access - you have to update the reference and the counter every time. That is a big performance hit. Reference counting may randomly halt your code, too, because you never know when you hit zero and the resource gets freed.

And you don't know how many resources will be freed when you drop the last pointer to that giant tree structure.

Of course, you could queue up and lazily delete the resources, but then you're back to nondeterministic behavior.

Two extra memory accesses plus whatever overhead for you have for locking if you are multi-threaded? That's pretty much the opposite of fast.

With refcounting you have:

  - Slow memory allocations (need to manage a fragmented heap)
  - Slow accesses and pointer handovers (updates to the refcounter)
  - Slow free (need to manage the free list)
  - No asynchronous pauses (since there is no garbage collector)

With a GC, you get:

  - Fast allocations (usually just an "add" instruction since the heap is not fragmented)
  - Zero cost accesses and pointer handovers
  - Zero cost free (just stop using the pointer)
  - Some asynchronous pauses and CPU usage while running the GC

It turns out that the cost of the first three points when using refcounting are much higher than that of the GC. Another reply to your post included references to actual research on this subject.

Reply on news.ycombinator.com