Objective-C Garbage Collection: Take 2

Based on the comments on both the original post here on Objective-C garbage collection and on John Siracusa's post, it looks like this is a hot button issue for some people. The biggest single issue is the perception that garbage collection means slow apps.

To me, this seems like a moot point in the grand scheme of things. At minimum, it's useless to worry about how fast or slow something is until we have it in our hands. Garbage collection isn't a new concept, and is rapidly becoming more the rule than the exception. We also know that computers are only going to get faster.

Combined with the basic need for easier programming and more stable software, this means that most Cocoa apps are going to be using garbage collection at some point. The only real question is whether it will be sooner or later.

There was a time that Quartz was called too slow to be practical, but it's just one instance of the rule that higher-level, more abstracted, more capable environments and APIs always win out in the long run. There's ample history to show what happens the developer of an OS or desktop environment gets tunnel vision and always turns down progressive APIs in the name of raw performance. Eventually, the platform ends up looking very dated.

Early on in the life of Mac OS X, some Mac developers even called Cocoa too slow for many types of applications. Those statements sound positively insane in today's environment. Cocoa has completely taken over the Mac development landscape.

All of this would probably also hold more weight if we hadn't heard this argument over and over again since the dawn of the microchip. C had no future because it was too slow compared to assembly. The same was said about C++ versus C, and the same about Java versus C++, scripting languages versus C/C++, and so on. Yet here we are.

The "Work is Good For You" Argument

Whilst reading through the FatBits comments, one really stood out at me. This one is by Rosyna:

As I've said before, this has no bearing on the quality of the OS itself but can make the quality of the applications much worse as cocoa does more and more for the developer. Case in point, when bindings came around and did almost everything for cocoa devs, cocoa devs thought it was great. But as soon as you start having a larger application that calls bindings many times a second, the performance starts to seriously degrade.

As Cocoa's barrier to entry decreases, so does the amount of knowledge required to use it which results in more applications of a lesser quality.

So many things. I really don't think garbage collection will make the quality of most applications worse. Few things are worse than an application continually crashing or leaking.

As for the second issue, not only is untrue that bindings does "almost everything" for the developer, but bindings can actually be faster than custom data population routines. Apple wants people to use this stuff, so they made sure it was very fast. For the most part, bindings is really just a standardized way to keep data synced between views and the model.

While simplified programming does mean less experienced programmers are more likely to publish software, it's not a point that's worth obsessing on. The potential benefits greatly outweigh the downsides. More people writing software for the Mac is overall a good thing.

More importantly, there are plenty of smart people with good ideas that can do memory management, but simply would prefer not to. There's no reason they should be artificially blocked from putting together great apps.

Bottom line: I can't see that garbage collection is going to be required -- at least not for quite a while. If you have good reasons to manage memory yourself, or simply like doing it, more power to you.
Design Element
Objective-C Garbage Collection: Take 2
Posted May 10, 2006 — 20 comments below


Daniel Jalkut — May 10, 06 1202

I agree. It seems like in the big scheme of things, automatic (or at least optionally automatic) memory management is a convenience whose time has come.

People who worry about the performance degradation this will have on the naive programmer's application seem to overlook the fact that new technologies with these caveats will always give veterans with perspective on performance an opportunity to easily outpace the competition. It's not like the world is going to become void of thoughtful programmers just because a new resource becomes available.

Chris Adams — May 10, 06 1203

I find these the anti-garbage-collection arguments amusing - is there a more extreme premature optimization? Of course novice programmers will write novice code - eventually they'll learn enough fixing those problems not to be novices; in the meantime everyone else can spend less time on bondage-and-discipline programming and more on fixing the algorithmic issues which are almost always the root cause of poor performance.

David Young — May 11, 06 1204

Interrupt my process every n/th of a second and give CPU time to *someone else's process*?! No way that'll ever work for important software like MOD players or Lemmings.

Dale — May 11, 06 1208

I'm not sure I agree with Rosyna's assertion that Bindings "did almost everything for cocoa devs, cocoa devs thought it was great" or that it decreases "Cocoa's barrier to entry".

Bindings requires a good understanding of MVC and certainly doesn't do everything (as Scott notes). You can't just use it to whip up a release-ready app like a RealBasic or VB6 programmer could.

I think it's more of an impediment to newbie programmers starting out 'cause it increases the learning curve.

Core Data's the same.

It appears to me that Apple are actually increasing the quality of third-party apps and their platform by providing a solid foundation for development/developers.

However, Objective C garbage collection won't necessarily be the same. It won't require a learning curve. But it won't result in a flood a garbage apps as Rosyna fears. It will very likely only be available to 10.5 and this limits its application.

Mike Abdullah — May 11, 06 1209

I think what is more relavent to me as a developer is how it will actually be implemented. I'm not too concerned about the performance (I'm sure Apple can do a decent job), it just seems to me that it could easily end up being only slightly easier to use garbage collection.

From a personal perspective, I have a pretty good grip on memory management now, and when I do I cock it up, it's generally due to an error in my design, rather than the lack of a garbage collector. I find that the memory management tends to correct me when I'm wrong!

Peter of the Norse — May 11, 06 1212

People have always written crappy software. It's not just a case of things being so easy that any idiot can make something. Just look at Lotus Notes. One of the worst programs ever, but written mostly in C++ with antique APIs. Their poor choice of development environment shows up in the program. If they had taken the time they spent working on memory management and used it work on the interface, the world would be a better place.

Preston — May 11, 06 1214

The easier it is for a developer to focus on his good idea and not nagging implementation details, the better.

Ken — May 13, 06 1222

[em]The easier it is for a developer to focus on his good idea and not nagging implementation details, the better[/em]
Exactly. This is so important its not even funny. This is why cocoa does better than anything out there right now, even with semi-manual memory management. Now if it gets a garbage collector, all apple really is doing is changing the official memory management policy to something better. Coredata, Bindings, Key-Value Coding, NSView/NSEvent etc is just the standard apple-approved way to set up MVC in cocoa thats all.

I like it better now, then before where it was basically target-action and do-it-all-yourself and you had to decide how an app works in many fundamental ways... now its more like we have to worry only about how it logically architected. This is basically what webobjects devs have had since forever btw. And if you still wanna roll-you-own everything in cocoa or obj-c you can still do it.

jean — May 14, 06 1229

Anyone know where to get basic GC info? Just curious!

Scott Stevenson — May 15, 06 1232 Scotty the Leopard

Anyone know where to get basic GC info

Could you be more specific?

Heiner M. — May 15, 06 1233

A specific garbage collector is described at www.ocaml-tutorial.org/garbage_collection - including some general points of consideration on the topic. A project that uses the conservative Boehm garbage collector for instance is nekovm.org.

Pierce — May 20, 06 1294

Actually, GC can be faster then all that retain/release stuff.

For instance in Java, with EOF, you can fetch 10,000 objects into memory much more quickly, because you just have to move the top of heap pointer 10,000 times. Malloc has to allocate 10,000 separate blocks instead.

That said, the other reality is that GC is to some extent a trade off. Do you do a .1 millisecond call 10,000 times over the course of an hour, or freeze for 20 seconds to GC?

In java, what ends up happening sometimes is that you end up explicitly setting pointers to null after you're done with them, just so that the GC system knows you're done with the object asap. So you've traded retain/release/autorelease for "release".

Personally, I think the GC system will function great as a way to debug leaks...

Scott Stevenson — May 22, 06 1319 Scotty the Leopard

because you just have to move the top of heap pointer 10,000 times. Malloc has to allocate 10,000 separate blocks instead

It's actually more complicated than that because all the object ivars have to be malloc'd as well.

On the other hand, you can sometimes avoid a lot of this overhead by doing a malloc of a large block of memory (sizeof(id) * 10000), and stuffing in the isa pointers in the appropriate places.

But yes, I understand the basic point you're making.

lambert — Nov 20, 06 2451

I have read that if you enable the garbage collection in Objective C, you can't mix and match with old non GC-ed code. Does this mean anyone who develops api addons for Objective C will need to develop two versions?

Scott Stevenson — Nov 20, 06 2461 Scotty the Leopard

Does this mean anyone who develops api addons for Objective C will need to develop two versions?

I really have no idea but it seems unlikely.

Lance Kay — Apr 25, 07 3970

I just decided to learn to program native OS X applications, and when I learned that Objective-C had no garbage collection I was disappointed and a little shocked. I've never had to manage memory in APIs I've used in the past, and I certainly wasn't looking forward to it. When I found out that garbage collection might be coming in OS X 10.5, I was excited about programming for Macs again. For me, G.C. is a goood thing.

firestorm — Oct 20, 07 4780

Garbage collection in Mac OS X 10.5 can be faster than retain/release on multi-core systems. retain/release requires the code to obtain a lock, which is expensive. On multicore systems, libauto (the GC) can examine the heap before it pauses the thread so it knows what it's doing going in. And, if there are UI events in the queue, it'll abort it's job and wait for the next idle time. It's probably the most advanced GC on the market.

Does this mean anyone who develops api addons for Objective C will need to develop two versions?
No, if you actually examine the Objective-C runtime in Tiger (available from Apple's open source downloads), you'll notice that the runtime will ignore retain/release/autorelease calls. (Runtime support was added in Tiger, the collector makes its debut in Leopard.)

Aleksey Gureiev — Nov 08, 08 6525

Not to disappoint you guys, I'm coming from the Java, C / C++ and Ruby world and can safely say that current incarnation of ObjC2.0 GC is nowhere near perfect and even good. It's a pity since I'm a 6-months old Mac convert who is blinded with the beauty and the elegance of Mac applications and API.

My poor impression of the GC is built on a practical experience rather than on theoretical speculations. A simple application with the table view in the main window shows it all. During the window resizing event handling, the internals of Cocoa allocate so many strings and integers that I run out of memory in less than 30 seconds. Memory profiler shows that the GC makes an effort to release memory blocks but irregularly and infrequently, which is obviously not enough to save the application from crash. If I perform window resizing in little steps releasing the mouse button all the time, the behavior is somewhat acceptable. Is it good? Not for me.

Personally, I find it a step back for myself to deal with memory allocation / deallocation in year 2008 after all these beautiful GC methodologies were discussed and implemented. Even Ruby, which is relatively new to the stage, has an almost perfect solution. Truth be told, RubyCocoa could be a great option should it provide a better integration with Cocoa internals (all these four-letter integer constants, third-party frameworks that you can't easily use etc). At least, Ruby GC is way superior.

The bottom line is: in early Nov'08 ObjC2.0 GC is still far from perfect. Very far.

Scott Stevenson — Nov 08, 08 6527 Scotty the Leopard

@Aleksey Gureiev: A simple application with the table view in the main window shows it all. During the window resizing event handling, the internals of Cocoa allocate so many strings and integers that I run out of memory in less than 30 seconds

It's hard to say what's going on without looking at actual code, but it would be unusual to run out of memory so easily in the circumstances you describe. Xcode, for example, is an incredibly complex app with some unusual memory needs which runs under GC.

It's possible that some minor tweaks to your code could work wonders. It's not uncommon for new Mac programmers to run into discouraging but easily-fixed errors early on in their work. I've spoken to countless individuals who told me that Core Data or Cocoa was lacking in some way, only to discover that they had made some wildly incorrect assumptions about how the language and frameworks behave.

I'm not saying this is necessarily the case for you, but you'd be in the company of some very talented programmers if it was.

Christoph Wendler — Aug 13, 09 6846

Since 2005 I have written several applications using Cocoa and Objective C. Last year I started to write a text editor using Cocoa, because in my job I had to deal with very specific programming languages for which there was no syntax highlighting. The editor features syntax highlighting, LatTex support, automatic substitutions etc. Having just moved to 10.5 at that time, I had the choice whether I wanted to adopt GC or use the old retain/release system. I decided to use GC for the new Cocoa project, although I knew that

a. the program would not run on older versions of Mac OS X
b. I might face some problems due to the GC framework still being buggy
c. I would lose direct control over memory management

As for a. and b., I think this is just a matter of time. Older versions of Mac OS X will simply disappear and the GC framework will be further enhanced.

As for c., I can understand that those who dislike GC fear that they lose control over the execution flow of their programs. It goes without saying that GC is not as efficient as allocating and freeing memory by hand. Still, for my part, I decided to hand memory management over to GC. Why? Because I believe that the goal of software development should be to write well designed and stable applications. Programmers spend a considerable amount of time trying to avoid memory leaks and dangling pointers. Even if you took great care while writing the code, you will find yourself skimming through the code from time to time checking all your release calls. Also, you will use debugging tools like ObjectAlloc to see whether you have overlooked something. This time is better spent improving the application's design and developing fast and stable algorithms. If an application performs poorly, this is more often than not due to slow algorithms. If the algorithm is bad, manual memory management won't make up for it. If you optimize your code according to Apple's Cocoa/Core Foundation guidelines as well as to general code optimization rules that help the compiler tweak your code, your application will perform well, even if GC is enabled.

Apple has done a great job enabling programmers to concentrate on the code that makes an application unique instead of having to do "monkey work". Interface Builder is a good example, as everyone knows who has ever worked with Java Swing or TKinter etc. GC is yet another way to boost programmers' productivity. This is what progress is all about. Remember the "law of diminishing returns" (cf. http://en.wikipedia.org/wiki/Diminishing_returns). For example, twice the effort/input does not necessarily yield results that are twice as good. If with effort 1 you reach up to 80%, you may only get 90% with effort 2, and only 95% with effort 3. If well written C code can be almost as good as hand-optimized assembly code, say up to 90%, why bother writing your programs in assembly language to squeeze out the last 10%? I think, this applies to GC vs. manual memory management as well.

I see no reason why new Cocoa apps should not be garbage collected, unless perhaps an application creates a myriad of objects and allocates loads of memory in a very short period of time. Yet, as far as I know, Apple's engineers are already working on a GC solution for these kinds of applications. Then again, sometimes allocating vast amounts of memory can also be a design fault.

While I still use manual memory management when I write small command line tools and the like, I prefer GC when working on bigger (Cocoa) projects, because it simply saves a lot of time and prevents my applications from crashing due to a silly oversight in the retain/release cycle. In the long run, GC is - for most applications - the way to go. In fact, I think GC in Objective-C was overdue.

Last but not least: Please note that if you want to develop Cocoa apps for the iPhone, you should stick to the old retain/release system as the iPhone does not (yet) feature GC.


Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.

Copyright © Scott Stevenson 2004-2015