Re: Performance problem with GC enabled
Re: Performance problem with GC enabled
- Subject: Re: Performance problem with GC enabled
- From: "Paul Sanders" <email@hidden>
- Date: Fri, 13 Mar 2009 16:04:36 -0000
> The most complex change is the move from -dealloc to
> -finalize. Finalizers are executed in an effectively
> random order whereas many people seem to want deallocs to
> be executed in a fixed, dependent, order.
> In reality, incurring order dependencies on -dealloc is a really bad
> idea; one unexpected -retain [leak] or -autorelease [order change]
> and the house of cards falls over (this has been a *huge* debugging
> time sink, in my experience). Finalizers force the issue by making
> ordered execution nearly impossible to achieve.
Yes, I agree with that (just got bitten by that one in fact). In the world
I am used to, destructors get called in a deterministic fashion (which I
like), but even in autorelease world you can't rely on that. For example,
when an NSWindow is release-on-closed, it gets dealloc'd, I just discovered,
*before* the NSViews it contains. This strikes me as dangerous actually, as
the NSViews might feel they are entitled to refer to the NSWindow in which
they reside until they are deallocated, but that seems to be the way it
works.
> Of course, you could choose to go down the route of using the various
> APIs to allocated collectable/scanned memory while using __strong and
> __weak to make the non-ObjC code more GC friendly. There will be an
> ever growing performance gain to be had in doing so, but it is very
> hard to get right. (The ObjC garbage collector is not actually an
> ObjC garbage collector -- it is entirely language agnostic. The
> "ObjC" part is that it is fully automatic with Objective-C, but must
> be manually integrated with everything else.)
Judging by a recent thread on this topic, it sounds safer to manage 'legacy'
mallocs / new's yourself. I personally wouldn't want the garbage collector
to interfere with this. But I haven't read the docs so I don't know what
the garbage collector brings to the party.
> The bugs at the border will typically be premature destruction of memory.
Ouch! Sounds like the key thing is a thorough understanding of how it
works.
I think ought to add that I am not using GC primarily because I want my code
to run on Tiger. I can see that it will be a big win for many Cocoa
programmers.
(Off topic again): Call me old-fashioned, but I don't like autorelease pools
all that much. I believe Cocoa could have gotten along just fine without
them, had they never been invented. I prefer C++-style 'smart pointers'
that delete (or release) themselves when they go out of scope. That way you
avoid the loss of determinism and potential memory usage peaks that
autorelease pools introduce and it's really not painful writing code that
way. It's a pity that Objective-C doesn't support such a construct - life
would have been so much easier. But it's far too late now.
Rgds - Paul Sanders.
_______________________________________________
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