On or about 8/10/08 4:37 PM, thus spake "Kyle Sluder" <[EMAIL PROTECTED]>:
> On Fri, Aug 8, 2008 at 9:02 AM, Matt Neuburg <[EMAIL PROTECTED]> 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 PROTECTED], 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
