i appreciate the reply ken. i'll try to answer your questions:
1. got it about the Object Alloc instrument. i'll have to spend some more
time with it to interpret everything and i will do so.
2. yes on the mutable arrays. besides memory issues if i didn't release and
then add objects correctly it would affect my results as well.
3. i'm actually not using -waitUntilExit with my task. maybe this is an error
i can correct. i have checked in the past and my task always shows completed
before i release it. also the rest of my thread would not work properly if the
task was not complete. but for an added safety i can put it. i know i can use
readInBackgroundAndNotify to get asynchronous results and i started this way
but i changed it because i got better results doing it on a thread. except for
of course these memory issues. but only one selector in background method has
a task the other 3 or 4 do not.
4. i don't believe i'm having a problem with the arrays being accessed the
same time by different threads. although i am not using a lock.
5. returning i am not doing. :-( maybe a bad error on my part. in the thread
method my first line i alloc/init an autorelease pool and the last line i
release the pool. should my last line be return? the method is void.
6. activity monitor in snow leopard shows the threads terminating but the
memory is not reclaimed. in leopard i do not see the threads terminating or
the memory being reclaimed.
at this point it seems my issue is with my threads. i have maybe 4 methods i
call by performSelectorinBackground and everytime i use this call i see the
memory jump. if i will test all the areas of my project and trigger all the
thread calls my memory will jump the most. once i will trigger one thread call
even if i will repeat that call in my project the memory will jump to a certain
point and that's it. but if i will trigger another thread call the memory will
jump again. i know i need to get this right as i originally tried getting
around using a thread by using a timer but it didn't quite cut it. thanks
again,
rick
________________________________
From: Ken Thomases <k...@codeweavers.com>
To: Rick C. <jo_p...@yahoo.com>
Cc: cocoa dev <cocoa-dev@lists.apple.com>
Sent: Saturday, October 3, 2009 7:15:13 PM
Subject: Re: memory advice for still learning coder
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 (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 arch...@mail-archive.com
