Re: garbage collection and NSConnection
Re: garbage collection and NSConnection
- Subject: Re: garbage collection and NSConnection
- From: "Michael Ash" <email@hidden>
- Date: Wed, 2 Jul 2008 21:33:34 -0400
On Wed, Jul 2, 2008 at 6:09 PM, Joan Lluch (casa) <email@hidden> wrote:
> Basically, all you have to do is to always return autoreleased objects from
> your methods, and always send release to objects that you created with alloc
> or were returned by any method containing "new" or "copy". Also, if you only
> use the standard accessor methods for setting properties, (which send
> release to the old object and retain the new one), you will not incur in
> any memory problem. It should not be that hard, and at the end your
> application will potentially perform better, and for sure it will eat
> significantly less memory.
I have to object to this bit at the end. It's a common cliche that
garbage collection makes your program perform worse and use more
memory. And certainly this is *possible*. But it's far from a given
these days.
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. 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. Whether
this is overcome by the overhead that GC gives you will depend on the
specific program.
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. This can result in large spikes in memory usage during
event processing. 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.
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".
Now, this is not to say that GC will make your program go faster. This
will depend greatly on exactly how your program is designed and
implemented. But while GC won't automatically make your program go
faster, it also won't automatically make it go slower.
Mike
_______________________________________________
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