Question

I watched Apple’s WWDC 2010 video on Advanced Memory Analysis with Instruments and from that, I was able to find a lot of resident dirty memory. I realize that having so much resident dirty memory is a bad thing (and probably the explanation for my app crashing so much…), but I’m not sure how to fix it. Where should I look?

Instruments shows me a lot of potentially useful information that looks like gibberish to me, such as:

% of Res  Type                      Resident Size
18%       VM_ALLOCATE (8192 pages)  32.00 MB

This is in the “Dirty” category – 32 MB of resident dirty memory is a lot on a device that only has 256 MB, right? 🙂 There are several more large chunks like this. How do I trace this back to my code from Instruments? Or should I just forget Instruments and look for specific issues in my code?

Answer 1

Do you see this 32 MB chunk of VM_ALLOCATE when running on the device or in the simulator?

I ask because when I played around with the allocations instrument on the OS X app I’m working on, I also noticed a 32 MB chunk of VM_ALLOCATE and I’m wondering if this is a by-product of running in the OS X environment. Running on the device may give you a different data set.

In general, though, resident memory is the memory that your app is using that is not swapped out to disk. On iOS, there is no swap, so resident memory should equal your virtual memory footprint.

Dirty memory is memory you’ve allocated and used. Dirty memory should be less than resident memory because the latter includes code (yours and frameworks).

I’m not sure exactly what you’re doing in your app, but I’ll guess that you’ve loaded some large assets from your bundle and are keeping them around. Don’t do this, when possible.

There are also APIs you can use when loading NSData objects that use a memory-mapping technique instead of brute-force reading the bytes. These can be better because it allows the OS to read the pages from disk lazily. With NSData (since it’s non-mutable), it might also be smart enough to mark the pages as read-only. Theoretically, this is a valuable hint to the OS that it can purge those pages when under pressure, since it knows they can’t change. Read the docs for +[NSData dataWithContentsOfMappedFile:].

For images, I recall reading something that suggested avoiding imageNamed: except for images that you regularly used through your app (i.e. UI elements). For large images especially, they can remain in a cache that you don’t have control over. (imageNamed: had a leak in the 2.x days, but it was fixed in 3.x and is perfectly safe to use today.) Use imageWithContentsOfFile: for larger images and images that aren’t a recurring part of your UI.

If you’re loading images from the network, cache them on disk and free the raw bytes after you create the UIImage. If the image views are unloaded due to memory pressure, you don’t want to hit the network to load the data again, but you also don’t want to keep two copies (an NSData and the UIImage) loaded.