Re: garbage collection and NSConnection
Re: garbage collection and NSConnection
- Subject: Re: garbage collection and NSConnection
- From: Marcel Weiher <email@hidden>
- Date: Thu, 10 Jul 2008 09:17:38 -0700
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 (email@hidden)
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:
This email sent to email@hidden