Re: memory advice for still learning coder
Re: memory advice for still learning coder
- Subject: Re: memory advice for still learning coder
- From: "Rick C." <email@hidden>
- Date: Sat, 3 Oct 2009 07:17:14 -0700 (PDT)
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 <email@hidden>
To: Rick C. <email@hidden>
Cc: cocoa dev <email@hidden>
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 (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