But GC has nothing to do with whether heap allocations 'slow the program down', it's who owns the lifetime of the allocated object - for GC not the programmer, but the runtime.
If I create a an object, and then then soon after deref it [MyObj release], then I know it will dealloc immediately after. I'm basically in control of its lifetime, even though it's ref counted.
If I call [MyObj free] and it's still owned by another object (e.g. I added it to some collection), that's OK because the object is still useful and has a lifetime outside of my control, and its destruction will be deferred until it doesn't.
But, with a GC object, if I call new MyObj() and then soon after try my best to destroy it, I can't because I'm not in control of its lifetime, the runtime is.
That's what I see the distinction between GC and ref counted (not GC), and why I mostly don't agree with so many people here insisting that ref counting is garbage collection. How can it be when I can easily be explicitly in control of an objects lifetime? I create it, then I destroy it, and it happens exactly in the sequence that I dictate.
For sure, ARC makes it a bit more subtle, but even then, I can reliably predict when an object will be destroyed and factor that into the sequence of events in my program.
-An Atheist.
But sure, tell me about his narcissistic story telling skills.
Because... they ruined it.