How can I get rid of resident dirty memory in Objective-C?

I watched Apple's WWDC 2010 video on Advanced Memory Analysis with Instrument开发者_StackOverflow社区s 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?

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.

With the new xCode 4 the tools coming from xCode 3 still there with a better user interface to profile your application including leaks and memory usage. I would recommend you to look at those tools and run one by one to see what are they providing you. You can access to those tools in xCode 4 on the main menu Product and then -> Profile

Hope this helps

In instruments click enable snapshots automatically Change view mode to regions map. Find in path names of files, which u r using while u application living in vmpages And after when u clear it. In video wwdc example they was using encryption for file and this was push it to vmpages, without u code too hard to suggest something more than [library flush] :-)

"This is in the "Dirty" category - 32 MB of resident dirty memory..." "I also noticed a 32 MB chunk of VM_ALLOCATE and I'm wondering..."

I see the same "VM_ALLOCATE (8192 pages) 32 MB" for resident, dirty, and virtual columns in the VM Tracker when I profile my apps in the Simulator.

For comparison, I've profiled the (smaller) demo apps built from Paul Hegarty's very informative iTunes U Stanford course -- e.g., Psychologist and the Graphing Calculator -- and see the same entry in each.

I'm a 'domain guy' and don't yet have a strong grasp of the details of memory management, so I can't offer an authoritative explanation, but it seems reasonable to conclude that this allocation is owed to elements of the Framework common to all apps run on the Simulator. (I haven't run them on a device.)

(FYI: Xcode 4.3 on a MacBook Pro running 10.7.3)