10

I've recently been developing an app that processes a large amount of data very frequently (~15 times a minute). To do so, I allocated a large chunk of memory, then freed it for each batch of data.

Here's a screen of my Memory Allocations from Instruments: The memory

The Memory usage oscillates from about 3MB to about 30MB pretty quickly. I was just wondering, is this "healthy," per se for the iPhone.

Is it risky to allocate and free so much memory so quickly? Is it unsustainable, or just bad practice?

Thanks!

pop850
  • 3,157
  • 3
  • 29
  • 34

3 Answers3

7

It is neither risky nor necessarily bad practice. Allocating and freeing memory takes time, so doing it very frequently vs. doing it once and re-using the allocated memory is a trade-off between memory usage efficiency (using the lowest amount of memory at every single moment) and performance.

If the performance of your app doesn't suffer at the moment, you have probably made the correct choice regarding this tradeoff for your app.

Generally speaking, using 30 MB of memory is quite a large amount for older devices (iPhone 3G and older). You cannot be sure that your app has that much memory available so be prepared to received memory warnings. If your app cannot reduce its memory usage when it receives a memory warning, the OS might kill it.

Christopher Moore
  • 15,626
  • 10
  • 42
  • 52
Ole Begemann
  • 135,006
  • 31
  • 278
  • 256
  • In my experience, anything over 20-25MB will cause an app to be killed on an iPhone 3G. pop850, you should test this on older devices (if you're interested in supporting them). That being said, if your app doesn't get killed with the first spike, doing it repeatedly probably won't kill it either. As long as there are no leaks. – nevan king Jan 30 '11 at 19:10
  • I think I'll have to do the processing in chunks so I use less memory, because I don't want to limit my audience to newer devices. However, that seems kind of puny, as I have allocated more than 180MB before without crashing on my iPhone 4. Many thanks for the answer. – pop850 Jan 31 '11 at 00:46
4

My primary worry in these situations would be fragmentation. If the chunks are all the same size though, you should be fine (and looking at your graph, the peaks appear to be completely level, so I think that's the case).

You will be paying allocation costs, but as Ole says, if your app is performing well enough already, there's not much point in trying to optimize that.

Catfish_Man
  • 41,261
  • 11
  • 67
  • 84
-1

It depends, if the user has an iPhone 4 or iPhone 3GS it should be do-able but on the iPhone 3G it will result in a memory warning very quickly. iPhone 4 has 256mb of RAM for the apps ( 512 mb in total ) iPhone 3GS has 128mb for the apps, and 256 in total the iphone 3g only has 128mb and 64mb for the apps.. usually having around 40mb free when no apps are running.

As apple says you should only allocate the memory you really need, and try to not use autorelease too much, because autorelease gives us an object being allocated while we don't really need it anymore

If the performance isn't too bad, I would try using less memory and allocating more when you really need it.

Antwan van Houdt
  • 6,989
  • 1
  • 29
  • 52
  • You should in fact use autorelease pools with autorelease objects and use them whenever necessary. – koo Jan 30 '11 at 15:07
  • @Adam Ko but then you should use release, in most cases you can retain count yourself and you won't need to make a pool yourself. Unless you are doing osmething in a loop that uses a lot of autoreleased objects you get through an API – Antwan van Houdt Jan 30 '11 at 15:11
  • Yeah, not sure what you mean. The behaviour as described in the question isn't going to cause a memory warning, unless you're allocating huge amounts of memory. Also, you're making some pretty big generalisations over how much memory is available, it's incorrect to say 'iPhone 4 has 256mb for apps (512mb in total)'. That's not how it works on the hardware. – lxt Jan 30 '11 at 16:31