> We find that an existing modern implementation of reference counting has an average 30% overhead compared to tracing, and that in combination, our optimizations are able to completely eliminate that overhead. This brings the performance of reference counting on par with that of a well tuned mark-sweep collector. [-3]
Even the best tuned mark and sweep GCs are a drag on performance.
> Reference counting is expensive - every time you manipulate pointers to an object you need to update and check the reference count. Pointer manipulation is frequent, so this slows your program and bloats the code size of compiled code. [-2]
> "Unfortunately, reference counting is expensive in both time and space". [-1]
Also, the slide entitled "Why reference counting is slow" in some recent lecture notes go into some detail. [0]
[-3] http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2...
[-2] http://ocaml.org/tutorials/garbage_collection.html
[-1] http://www.rtsj.org/RTJPP/errata.html
[0] http://cs.nyu.edu/courses/fall12/CSCI-GA.2110-001/lectures/G...
Please don't thoughtlessly replace pointers with shared_ptrs in an attempt to prevent memory leaks; shared_ptrs are not a panacea nor are they without costs:
-a circular linked structure of shared_ptrs will cause a memory leak (you'll need some logical complication to break the circle, e.g. using a weak_ptr)
-"shared ownership objects" tend to stay "live" for longer than scoped objects (thus causing higher average resource usage)
-shared pointers in a multi-threaded environment can be expensive (because of the need to avoid data races on the use count)
-a destructor for a shared object does not execute at a predictable time, and the algorithms/logic for the update of any shared object is easier to get wrong than for an object that's not shared
