views:

149

answers:

3

This is a pretty weird question I guess, but I've never really had to deal with memory allocation before so now I'm really paranoid about using too much of it or forgetting to deallocate stuff. I've found the extremely useful memory leak tool (and am quite proud to see that, so far at least, I'm not losing anything that way) and also the Allocations tool which I assume is for measuring how much memory is used up at any given point of application runtime. However, I'm not really certain how much memory I should be using up.

I think there's a good 256M in my iPod touch, not too sure, but I don't know how much of that is taken up by system processes, nor really how much I can safely use before I start running into low memory issues. At the moment my program's taking up around 4 MB, which seems pretty high for what it's doing but I guess at least some of that is system processes that can't be stopped, or high-maintenance stuff like the large graphical backdrop I'm using.

In short, can someone give me a good benchmark figure that my applications should aim for in terms of the maximum amount of memory used at any given time? Figures for iPhone 4 and iPad would be nice too, if these differ significantly.

-Ash

A: 

For the last 2 days I am analyzing the memory footprint of my latest app and I discovered an interesting fact:

My app sometimes invokes -(void) ApplicationDidRecieveMemoryWarning:(UIApplication*) app @ about 4.5mb allocated in the heap. When it does, it has one implication IT KILLS SOME AUTORELEASED OBJECTS which should be otherwise kept intact. Once app attempts to run a selector on Zombied object, the app crashes. I manage most of the memory manually, so it's not a big issue for me. If I'd reboot my phone it can handle up to 8mb in the heap without any warnings. I guess in iOS4 it depends how much stuff you run in the background as well. I have iOS 4.0.1 on iPhone4.

iPad/iPhone 3GS have 256mb, iPhone4 has 512mb, however it does not mean its all available to a process. I remember in early iOS 3.0 one of my apps was terminated by OS at 32mb.

bioffe
These are not autoreleased objects being deallocated. Autoreleased objects are deallocated when their autorelease pool is deallocated or drained. The main pool is drained at the end of the current run loop, not in response to memory warnings. Most likely what you are seeing is the deallocation of views that are no longer on the screen (a standard UIViewController response in the didReceiveMemoryWarning method). Also, if you use the Memory Monitor instrument you will see that the true size of your application is much larger than the 4.5 MB of allocations you describe.
Brad Larson
@Brad You are absolutely correct. It deallocates views.
bioffe
A: 

This is a pretty frequent question, as you can imagine.

Last time it came up, I gave my two cents. That's here: http://stackoverflow.com/questions/3448583/memory-uses-limit-on-iphone/3449344#3449344

Dan Ray
Thanks. I did search for similar questions before asking, but I must not have used the right criteria or something.
Ash
No worries. That's why Tim Berners-Lee gave us hyperlinks.
Dan Ray
A: 

There's no hard answer. There are a few things to note:

1) If your app uses more and more memory over time, it will be killed a lot sooner than an app that releases memory properly most of the time, but makes a few mistakes. Don't forget there is a watchdog process that has a (seemingly) complex formula for killing applications, and that different apps can be killed at different levels of memory use for different reasons.

2) The iPhone4 has a lot more memory than the previous phones BUT with users multitasking, it's really rude to just go to town with memory use. With multitasking here it's more important than every to keep your memory footprint low (and it helps when your own app is in the background, the more memory is uses the more likely it is to be killed).

3) Treat memory warnings seriously and dump EVERYTHING you can. It will keep your app running longer and again help it live on in the background for a longer time.

Kendall Helmstetter Gelner