How can I get rid of resident dirty memory in Objective-C?
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?
- Bug with starting Instruments via Profile under XCode 4.1 Build 4B110
- does an entry in Instruments “leaked block” during application running imply memory leak?
- How do I reliably get Instruments 4.x to symbolicate?
- iPhone 4 profile power consumption (with instruments)
- XCode instruments not reporting any data
- Is there anyway to read performance counters on OS X Mountain Lion?
4 Solutions Collect From Internet About “How can I get rid of resident dirty memory in Objective-C?”
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
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
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)
- Email & Phone Validation in Swift
- deprecated warnings in xcode and how to handle deprecation
- Can't change search bar tint color to be transparent in iOS 8
- How to capture the URL used to launch an OSX application via URLScheme in Swift?
- DebugLog Format string is not a string literal
- Customise NSLog so it shows less info
- Is it possible to have a nil value in a tuple with Swift?
- Pass data from tableview to tab bar view controller in Swift.
- Animate text change in UILabel
- Learning OpenGLES 2.0 on iOS
- How can I get a precise time, for example in milliseconds in Objective-C?
- Identifying the country code using mobile carrier in iPhone Programatically?
- Simulating System Wide Touch Events on iOS
- How to stop the execution of tasks in a dispatch queue?
- How to use NSWritingDirectionAttributeName in swift?