There is no a priori reason to think that it isn't horrible in terms of CPU time. Anything that has to do more work just to manage memory is going to consume cy

There is no a priori reason to think that it isn't horrible in terms of CPU time. Anything that has to do more work just to manage memory is going to consume cycles, and usually a lot of them. In simple utility programs it might not be observable but in larger applications with more objects, or on slower hardware (phones, for example) the cost is palpable. > 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-2012.pdf http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2... [-2] http://ocaml.org/tutorials/garbage_collection.html http://ocaml.org/tutorials/garbage_collection.html [-1] http://www.rtsj.org/RTJPP/errata.html http://www.rtsj.org/RTJPP/errata.html [0] http://cs.nyu.edu/courses/fall12/CSCI-GA.2110-001/lectures/GC.pdf http://cs.nyu.edu/courses/fall12/CSCI-GA.2110-001/lectures/G...