Design Element
Comment on "Objective-C Garbage Collection: Take 2"
by Aleksey Gureiev — Nov 08

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.

Back to "Objective-C Garbage Collection: Take 2"
Design Element

Copyright © Scott Stevenson 2004-2015