Re: NSImages are killing my WindowServer
Re: NSImages are killing my WindowServer
- Subject: Re: NSImages are killing my WindowServer
- From: Troy Stephens <email@hidden>
- Date: Thu, 23 Mar 2006 13:34:30 -0800
On Mar 23, 2006, at 12:01 PM, James Bucanek wrote:
Troy Stephens wrote on Thursday, March 23, 2006:
On Mar 23, 2006, at 10:35 AM, James Bucanek wrote:
John Stiles wrote on Thursday, March 23, 2006:
See if your idea of releasing them sooner helps.
You could also use ObjectAlloc to see just how many NSImages you're
making... it may be more than you expected!
I think you're right about the number. Looking at the code again, I
think it could approach a thousand or more at a time.
Anytime you let autoreleased objects pile up, you're deferring
reclamation of the resources they own (memory, and in this case
offscreen windows as well) until they objects are finally
deallocated. It sounds as if in this case your code would benefit
from setting up a local (aka "nested") autorelease pool in an
appropriate place (e.g. just inside the loop where you iterate over
your N images to be processed).
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/
Concepts/AutoreleasePools.html
Thanks Troy, but the situation a tad more complicated. I already
have temporary autorelease pools set up, but these are in separate
worker threads. The producer threads create the objects, which are
then passed to consumer threads via a queue where they get
processed and released. Each producer thread maintains a temporary
autorelease pool that it releases from time-to-time. But just to
make things more interesting, the producer code is recursive. So
the producer thread could have 20 or more nested autorelease pools,
each with scores of objects that have accumulated. So the peek
number of autoreleased object can be rather high, and there's no
simple code alteration that is going to change that.
In that case, you are probably better off keeping the generated
images out of your autorelease pools altogether (if you can), and
handing them off to your receiver thread with a clear "caller takes
ownership and is responsible for releasing" semantic.
For my really heavy-weight objects I've taken to creating pairs of
methods: One that returns an autoreleased object and one that
returns a retained object. This lets me immediately release objects
with large footprints. But I don't have this luxury (can doing your
own memory management be considered a luxury?) with many of the
Cocoa objects.
Which other kinds of Cocoa objects (besides NSImages) are piling up
and causing problems?
Troy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden