Re: Performance problem with GC enabled
Re: Performance problem with GC enabled
- Subject: Re: Performance problem with GC enabled
- From: Kyle Sluder <email@hidden>
- Date: Fri, 13 Mar 2009 13:39:33 -0400
On Fri, Mar 13, 2009 at 1:30 PM, Paul Sanders <email@hidden> wrote:
> That's very interesting, I didn't know that attribute existed. I imagine
> that post-dates autorelease pools by some years.
It's a relatively new GCC-ism.
> But most objects returned
> by framework functions are autoreleased which means you can only get rid of
> them by bracketing them with an autorelease pool.
If you're using NSApplication, you already have an autorelease pool.
If you need it cleared more frequently, then yes it's your problem to
create a new one.
> This bugs me somewhat and
> is obviously less efficient than just throwing them away when you are done
> with them.
No, it's not. Without any sort of management, you'd leak memory like
crazy in situations where neither the caller or the callee can release
the object.
> But it does let you pass @"string" as a function parameter I
> suppose without having to release it afterwards.
@"" strings are baked into your binary as instances of
NSConcreteString. They are not autoreleased.
> Still can't say I like it
> much.
Well at this point, the only useful advice anyone can offer you is
"Deal With It." Academic discussion on the merits of autorelease
pools unfortunately won't help your project.
--Kyle Sluder
_______________________________________________
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