[algolicious]

Reference counting does have runtime overhead, though. Incrementing and decrementing references as a reference gets passed around isn't free. If you have many small objects, the reference count itself may become a significant memory overhead. Furthermore, GC means that memory allocation can be done by allocating at the top of the heap instead of a more expensive malloc, and freeing garbage may be literally free depending on the algorithm used. When an object falls out of scope in a reference counted world, it is typically immediately freed - if this is a handle into a large recursive data structure, for example, it can definitely suck up cycles. Counterintuitive as it may seem, GC can be the cheapest solution in some circumstances, unless your program eschews malloc entirely.

[ryannielsen]

Yes, GC can be faster in some scenarios. I'll never get into a dispute about what's faster... legitimate arguments can be made both ways.

My point about profiling the exact user experience still stands. I can exactly instrument the hotspots in my code and fix them as needed – I can disable ARC, I can avoid autorelease pools. (Or I can add my own autorelease pools or manual retains, preventing large objects from being freed until I'm outside of a hotspot.) Importantly, I know what's being profiled is exactly what will be run by my users. I can't say the same about GC code, since the collector must be free to reap whenever and however it decides. Heck, depending on the runtime, I can't even be certain which GC algorithm will be used by my customers.

I appreciate the control refcounting gives me, and I love that ARC makes writing refcounted code almost as painless as writing GC code without the loss of control. I like being able to test and profile exactly what my users will run.

[Scaevolus]

Another nice thing about refcounting versus other garbage collection strategies is that it can have more deterministic memory access patterns-- including possibly preventing heap fragmentation.