Re: Does [NSApp setApplicationIconImage] leak memory?
Re: Does [NSApp setApplicationIconImage] leak memory?
- Subject: Re: Does [NSApp setApplicationIconImage] leak memory?
- From: Matt Neuburg <email@hidden>
- Date: Sun, 10 Aug 2008 17:04:26 -0700
- Thread-topic: Does [NSApp setApplicationIconImage] leak memory?
On or about 8/10/08 4:37 PM, thus spake "Kyle Sluder"
<email@hidden>:
> On Fri, Aug 8, 2008 at 9:02 AM, Matt Neuburg <email@hidden> wrote:
>> Wrap each call to setApplicationIconImage in an autorelease pool creation
>> and release, like this:
>>
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> [NSApp setApplicationIconImage: whatever];
>> [pool release];
>
> Okay, sorry for jumping in late, but I don't understand how this would
> solve the problem. Since we're talking about NSApplication, AppKit
> has already created an NSAutoreleasePool, so it's not like
> -setApplicationIconImage: is autoreleasing an object when there's no
> autorelease pool stack. Therefore, regardless of whether it's an
> AppKit autorelease pool or your own autorelease pool, any autoreleased
> object will still only get one -release message. Creating your own
> autorelease pool should only make it happen "now" instead of "later".
That's perhaps perfectly true. But "later" could be a LOT later - and in the
meantime quite a lot of memory could pile up. For example, it is the nature
of the Cocoa event loop that the autorelease pool gets cleaned out when the
user switches to another app and back to your app. But that might not happen
for quite some time. To cite an example in my own life, in an app where I
was creating a lot of autoreleased strings as I gathered data from a huge
MySQL database, I actually caused my computer to freeze up for lack of
memory. When I created my own autorelease pool and released it every n times
thru the loop, the problem went away. This is, indeed, an *extremely* common
technique for doing exactly what you say - making it happen "now". You can
read up on Cocoa memory management here:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concept
s/AutoreleasePools.html
Notice in particular this phrase:
> If you write a loop that creates many temporary objects, you may create an
> autorelease pool inside the loop to dispose of those objects before the next
> iteration. This can help reduce the maximum memory footprint of the
> application.
So, to resume, it may in fact be that the OP's app is NOT truly "leaking" -
but rather, that exactly what I'm describing here is what's happening to
him: the built-in autorelease pool is just piling up and not getting
released, because the event loop hasn't exited yet. The fact that the
problem he is seeing does in fact go away for him when he does what I
suggested is an indication that it is. This is one of the possible
conclusions towards which, in my Socratic little way, I'm trying to lead the
OP. Stay tuned. m.
--
matt neuburg, phd = email@hidden, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
AppleScript: the Definitive Guide, http://tinyurl.com/2ouo3b
Take Control of Customizing Leopard, http://tinyurl.com/2t9629
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
_______________________________________________
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