Hacker News new | ask | show | jobs
by rimantas 5672 days ago
Garbage collection on OS X appeared in Leopard with Objective-C 2.0—later than iPhone, but before iPhone SDK. Older models are still around and even iPad has less memory than iPhone 4 so it is not unreasonable to treat it as resource too precious to be left ar the mercy of GC. On the other hand, manual management is not that complicated and does not add much overhead in programming except the initial phase of getting used to it.
3 comments

If they do ever introduce it, I sincerely hope it is completely optional. On my iPad app, I run with such tight memory constraints while dealing with large image files that it has to be freed up when I tell it to or I'm likely to get killed by the memory watchdog.
The existence of a garbage collector doesn't mean that the programmer has to play a totally hands-off role in the allocation of objects; as with any coding, there are usually a few bottlenecks that deserve special care. A system with a good GC will provide opportunities to tune; for example, to make hints to the GC about lifetime and locality and so on.

http://www.jwz.org/doc/gc.html

I would expect it would be if they follow the pattern from OS X. I do wonder what the breakdown in new OS X apps between GC and retain/release.
I treat memory as a resource too precious to be left to the mercy of programmers. In any application, a good garbage collector can be more efficient than malloc/free or new/delete.

http://www.jwz.org/doc/gc.html

How about compared to retain/release/autorelease?
?? I admit the last time I really coded in Obj-C was for NeXTSTEP. But back then init ultimately called malloc, and release ultimately called free. In any case, yes, a good GC can be faster as it takes advantage of cache effects.
I upvoted you, but I was mostly just quoting the jwz article from 1998.
Older iPhone models cannot run the current OS anyway.

And manual memory management is not a showstopper, but to say it's "not that complicated and does not add much overhead" is just wrong. It's conceptually simple, but the devil is in the details. I would bet that if you took a poll of all Cocoa programmers who have been working in the field since — well, pick any date you think qualifies as "out of the initial phase" — and ask them how many of their programs have done correct memory management without debugging, you will get an answer of 0.

  Older iPhone models cannot run the current OS anyway.
This is true only for the oldest (1st gen). iPhone 3G and 3GS run 4.2 just fine. Sure, some of the most prominent features of iOS 4 are missing on 3G, but it still does not qualify as not running.
I don't disagree with the premise that memory management requires more work; however, the tools and utilities that Apple now provides to hunt down memory issues makes it more tedious than difficult.