Which memory usage reporting method should I use when my application crashes due to low memory? There are few options:
Allocations instrumentation tool
Activity Monitor instrumentation tool
VM Tracker instrumentation tool
Xcode debugging sessions memory reporting
mach_msg_type_number_t.resident_size
The problem is that every method returns different results.
Allocations instrumentation return much smaller values than other methods - I assume Allocation only counts memory explicitly allocated inside application, but not memory used by my my app code and other libraries code? Am I right? On 512MB devices Allocation reports as low as 70MB of allocated memory and application still receives memory warnings and eventually crashes. Can I somehow measure what this difference is exactly?
Xcode debugging sessions memory reporting and mach_msg_type_number_t.resident_size varies vastly. They are sometimes 50MB away from each other, both ways. Why is that?
I would like to test APP in the process of running the physical memory occupied, the first way is to use xcode debugging APP, Memory Report shows real-time occupied physical memory, only about 90 MB; The second way to use Activity Monitor detection APP, In the Detail-> Summary-> Samples Real Memory display up to 200MB or so.
So I am confused, which value can really represent APP physical memory occupied?
Xcode Memory Use
AM Real Mem
An iOS app can be using 90 megs of actual RAM but it will typically have a lot more space as memory mapped files. These could be shared libraries or just files that you explicitly mmap. While iOS will kill your app if you use too much RAM memory, you can actually use quite a bit more mmap memory, up to about 650 Megs without getting a memory warning. The readout showing memory use directly in Xcode is your best readout for active RAM memory.
I'm attempting to download a large number of images using AFNetworking 2.5 and stream them to disk. According to the memory monitor in Xcode, this is causing unbounded memory growth (and eventually memory warnings and force quits) - but profiling the memory usage using the allocations instrument shows the memory usage to be stable.
I'd like to think Xcode is just wrong here, but then why would my app be getting killed by iOS?
Instruments shows this - the peaks are Core Data queries, then the rest is the images downloading - peaks at about 9.5MB, the rest sits at about 8.5MB
I've also tried Heapshot Analysis - which shows a tiny bit of growth but nowhere near the amount reported by Xcode
Xcode's memory monitor shows this - growing by multiple MB per iteration.
Is there any way to get Instruments to show me whatever Xcode is seeing? Or is there a better instrument to use to find out where all this memory is going?
Thanks!
According to the memory monitor in Xcode, this is causing unbounded memory growth (and eventually memory warnings and force quits) - but profiling the memory usage using the allocations instrument shows the memory usage to be stable.
Believe Instruments and the Allocations information - not the memory monitor in Xcode. The memory monitor graph is completely irrelevant. Ignore it.
This is not because the memory monitor in Xcode is useless or wrong. It is because memory management is completely different for a debug build than for a release build (Instruments uses a release build). This is especially true in Swift (you don't say whether you're using Swift).
Observe memory usage only on the device and only in a release build. Otherwise, you'll be completely misled.
I hava an application . when I repeat some action , anonymous allocations memory continuously increase a lot while heap allocations increase a little. can some one help me ? Thanks
Focus on the Live Bytes column for All Heap Allocations to see how much memory your application is using. You cannot control your application's Anonymous VM size.
Focus on the heap allocations because your app has more control over
heap allocations. Most of the memory allocations your app makes are
heap allocations.
The VM in anonymous VM stands for virtual memory.
When your app launches, the operating system reserves a block of
virtual memory for your application. This block is usually much larger
than the amount of memory your app needs. When your app allocates
memory, the operating system allocates the memory from the block it
reserved.
Remember the second sentence in the previous paragraph. The operating
system determines the size of the virtual memory block, not your app.
That’s why you should focus on the heap allocations instead of
anonymous VM. Your app has no control over the size of the anonymous
VM.
Source: http://meandmark.com/blog/2014/01/instruments-heap-allocations-and-anonymous-vm/
I'm definitely confused on this point.
I have an iPad application that shows 'Live Bytes' usage of 6-12mb in the object allocation instrument. If I pull up the memory monitor or activity monitor, the 'Real Memory' Column consistently climbs to around 80-90mb after some serious usage.
So do I have a normal memory footprint or a high one?
This answer and this answer claim you should watch 'Live Bytes' as the 'Real Memory' column shows memory blocks that have been released, but the OS hasn't yet reclaimed it.
On the other hand, this answer claims you need to pay attention to that memory monitor, as the 'Live Bytes' doesn't include things like interface elements.
What is the deal with iOS memory footprint!? :)
Those are simply two different metrics for measuring memory use. Which one is the "right" one depends on what question you're trying to answer.
In a nutshell, the difference between "live bytes" and "real memory" is the difference between the amount of memory currently used for stuff that your app has created and the total amount of physical memory currently attributed to your app. There are at least two reasons that those are different:
code: Your app's code has to be loaded into memory, of course, and the virtual memory system surely attributes that to your app even though it's not memory that your app allocated.
memory pools: Most allocators work by maintaining one or more pools of memory from which they can carve off pieces for individual objects or allocated memory blocks. Most implementations of malloc work that way, and I expect that the object allocator does too. These pools aren't automatically resized downward when an object is deallocated -- the memory is just marked 'free' in the pool, but the whole pool will still be attributed to your app.
There may be other ways that memory is attributed to your app without being directly allocated by your code, too.
So, what are you trying to learn about your application? If you're trying to figure out why your app crashed due to low memory, look at both "live bytes" (to see what your app is using now) and "real memory" (to see how much memory the VM system says your app is using). If you're trying to improve your app's memory performance, looking at "live bytes" or "live objects" is more likely to help, since that's the memory that you can do something about.
Seeing as how I wrote the last answer you linked to, I'll have to stand by that. If you want a total, accurate count of the current memory usage for your application, use the Memory Monitor instrument.
For reasons that I describe in this answer, Allocations hides the memory sizes of certain elements, meaning that its memory usage totals are significantly lower than your application's in-memory size. Many people find this out the hard way when they try to get their application functional on older iOS devices. On the older hardware, you had a hard memory ceiling of ~30 MB, where if you exceeded that your application was hard-killed.
Many developers (myself included) saw that we only had ~1-2 MB of live bytes in Allocations and thought we were good, until our applications started receiving memory warnings and early terminations. If you looked at Memory Monitor, you could see the true in-memory size of these applications being >20 MB, and you could see the applications being terminated the instant they crossed the 30 MB barrier in Memory Monitor.
Therefore, if you want an accurate assessment of your total application memory usage, use Memory Monitor. Allocations is great to find out the specific objects that are in memory, particularly when you use the heap shots to find things that might be accumulating (as leaks, retain cycles, or for other reasons). Just don't trust it when determining your application's actual size in memory.
'Live bytes' means memory allocated by your code (for example by malloc), so you have access to this memory. 'Real memory' shows physical amount of memory used by your app. This include also OpenGL textures, (possibly) sounds from Open AL...
Live bytes is useful to check when you allocate and release memory in your code. Real memory is good indicator for memory optimization efficiency. And it's overhead causes 'low memory' warnings.