Re: memory advice for still learning coder
Re: memory advice for still learning coder
- Subject: Re: memory advice for still learning coder
- From: Ken Thomases <email@hidden>
- Date: Sat, 3 Oct 2009 06:15:13 -0500
On Oct 3, 2009, at 2:38 AM, Rick C. wrote:
i'm having a few memory issues where my memory climbs over time
although using leaks it shows i have no leaks.
Leaks aren't the only way to use excessive memory. For example, if
you keep allocating objects and putting them in a collection somewhere
(like the mutable arrays you describe below) but never use them and
your code effectively forgets they are there due to a logic error,
they haven't officially leaked but the effect is similar.
You can use the Object Alloc instrument. When examining the recorded
data, you can select a range of data. Set its beginning to a point in
time after your app should have reached equilibrium -- after it has
set up those objects which are meant to stick around for the whole
lifetime or your app. Set the end of the range to any point afterward
where the memory use has inexplicably risen. Tell the instrument to
show only the still living objects. This effectively shows you
objects which were allocated and expected to be temporary, but which
are still around.
1. i have a handful of mutable arrays that i need for the lifetime
of my app. i alloc/init them upon startup and at various places i
do removeAllObjects and then addObjectFromArray with the other array
being convenience created. in dealloc i do release.
So long as you really are invoking removeAllObjects when you expect to
be, and the other array only contains what you think it should, that
sounds fine.
2. i use NSObject performSelectorInBackground for a few methods so
they do not tie up my main thread. one of these background methods
uses NSTask. in every background method i init the autorelease pool
and release it according to the docs. i also release the NSTask i
use.
There have been reported issues with NSTask: if you don't run the run
loop of the thread from which it was created and launched, then it
might not clean up its resources. -waitUntilExit should be
sufficient. If you're not waiting for the NSTask to complete, then
there's little reason to launching it from a background thread. So,
you might be better of launching it from the main thread, where
there's extra effort required to make sure the run loop is run. In
fact, you can always use an NSTask from the main thread in an
asynchronous fashion, and that may be a better design choice,
depending on what else your background thread is doing.
and i do modify a few of the above mentioned mutable arrays in
these background methods in the way i described above.
I hope you're being careful to properly guard against multiple threads
accessing any given mutable array at the same time.
i'm trying to pinpoint where the problem can be and it seems
everytime i initiate performSelectorInBackground my memory usage
goes up and is not reclaimed. i know starting a new thread
increases memory but i'm expected it to be reclaimed.
Of course, you have to allow the thread to exit by returning from the
method named by the selector. I assume you know that. :)
Does Activity Monitor show the thread count of your app steadily
rising, or does it fall back to equilibrium when it should?
Regards,
Ken
_______________________________________________
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