Some minor factual corrections:
On Jul 2, 2008, at 18:33 , Michael Ash wrote:
In Cocoa you do lots of retaining and releasing. These operations aren't free. They involve a lookup into a global hash table and some sort of atomic increment/decrement operation.
The hash table is only used by NSObject subclasses that do not implement their own inline reference count. Most Foundation objects do implement such an inline reference count, so there are no hash lookups involved, just the atomic increment/decrement. I would strongly recommend that you implement an inline reference count for your own objects if they undergo frequent ownership changes.
They're pretty fast, but there's certainly some cost there. Garbage collection lets you eliminate all of this code, so you get a speed bonus there.
GC does not eliminate this overhead, it replaces it with the overhead of the write-barrier functions that are called when you do an assignment. These calls are generated automatically by the compiler, so you don't see them in your code, but they are still function calls. This is in addition to the scanning overhead.
The question of memory usage is far from a given, especially in Cocoa where you do lots of autoreleasing. The pervasive use of autorelease essentially means that objects don't go away until you go back to the event loop.
They generally go away whenever you want them to go away. The top of the event loop is a good default, but it is just that: a convenient default.
This can result in large spikes in memory usage during event processing.
If you see such spikes, simply add autorelease pools to your processing. Also: don't gratuitously create and/or autorelease objects if you don't have to. Objective-C object-creation is pretty heavy-weight compared to other OO languages, regardless of wether you are using garbage collection or reference counting, so programming- styles that do a lot of object-creation will suffer, performance-wise.
With RC, there are ways to mitigate the effects ( see http://www.metaobject.com/blog/2007/08/high-performance-objective-c-i.html and http://www.metaobject.com/blog/2007/09/more-on-mpwobjectcache.html ), whereas I haven't yet found a way to achieve the same effect with GC.
The collector isn't constrained by the event loop and can run any time it wants to, so it can potentially prevent these spikes from occurring. This also has a performance impact, as a more memory efficient program is also a faster program due to having a smaller working set.
You can achieve the same effect by inserting autorelease pools during processing.
Cocoa's GC also has another interesting advantage: most of the work is done on a background thread. This means that on any multi-core machine (which is any Mac sold in the past couple of years) that isn't already loaded at 100%, this bulk of the GC work essentially comes "for free".
...as does doing the work during the top of the event loop when the machine is waiting for user input. Of course "free" is actually not free (a) in terms of power consumption and (b) in terms of memory bandwidth, which is a shared resource between the cores and frequently the bottleneck these days and (c) if you have other work for that core.
Cheers, Marcel _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
