Leaks:
None
ObjectAlloc:
Net Bytes: 4,332,512
# Net: 26,696
Overall Bytes: 103,769,552
# Overall: 738,987
Activity Monitor (MyApp):
# Thread: 6
Real Memory: 63.65 MB
Virtual Memory: 209.45 MB
Memory monitor showed same readings as Activity Monitor. I don't know whether these readings are good or bad. Memory indicated by Activity Monitor is horrifying. Should i be worried? Can i somehow estimate memory used by the application once its moved to the device. The real run time memory? Thanks.
Memory usage as reported by Object Allocation is not very autoritative, at least according to my experience. The real deal is the real memory consumption as reported by Memory Monitor, see my question on iPhone memory consumption. Your numbers seem to be measured in Simulator, such measurement is worthless. You have to measure on the device.
Object Alloc is reporting to the total memory used over the entire lifespan of the run. That means if objects are allocated and deallocated (which they often are) you see all the memory consumed in total.
Far more useful is to select the option "created and still living", then highlight regions of the graph where memory increases but it never goes down if you expect it would. Then you can see how much memory is being allocated at that point and what is allocating it. This works in the simulator as well as the device.
Related
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 am stuck with an issue in my app. I have been testing up until now mostly on my iPad 3 with occasional checks on my iPad 1 to make sure all is well.
I am playing a UIImageView animation in my app and it keeps quitting with only a "Received memory warning" message before it quits.
I have been using the Object Allocations tool in instruments but according to that, my memory usage is way low. So after researching for a bit I came across this post by Mr. Larson: https://stackoverflow.com/a/5627221/329900
Now I am using the Memory Monitor tool instead. However, I don't understand why I am quitting. The 1st gen. iPad has 256MB of ram. Now I know I can't use all of that...some say you shouldn't use more than 100MB.
Is that real memory though, or virtual memory...or maybe some combination? My real memory is consistently between 20 - 25MB but the virtual is around 190 - 205MB when it crashes.
Here's a screenshot:
Anyone able to shed some light on this?
The WWDC (Session 242) video found by searching for iOS App Performance: Memory in the WWDC 2012 Session Videos page will give you a better understanding of the difference between VM and real memory.
But here is a quick overview:
A pointer Range = 2^32 = 4GB This is larger then the physical memory on any device(apple has shipped). This is done by taking all available space and dividing it up into 4kb chunks. Not all the memory your application can access is in physical memory at the same time. These 4kb chunks are call pages. Your allocations get split out of larger chunks of virtual memory. Then these virtual memory objects get mapped to physical memory.
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.
I have code that has a low amount of active allocations (about 5 MB according to Instruments), but a high amount of system memory usage (over 100 MB). I know the code is leak-free, and I'm not seeing any allocation spikes after some optimization, but I'm still crashing due to the high amount of memory usage.
I Googled around a lot and see that I'm supposed to be using the VM Tracker instrument, which confirms my high memory usage, but I'm not sure how to address this situation. I'm using as little memory as possible, it's still too much on an iPad 1, and I don't have the knowledge or tools to figure out how to get the OS to not mark so much memory as dirty when I'm not actually using it. Where do I go from here?
Use the Profile tool and select memory +allocations. Click the VM tracker and take a snapshots. This results in a list with resident dirty and virtual memory usage per object type. This will give you an indication where to look.
I think the most common problem is that you have a lot of autoreleased objects that reside in the autoreleasepool. The following link explains more on how to handle autoreleasepools:
How does the NSAutoreleasePool autorelease pool work?
I want to make sure I'm reading the allocations plug in correctly. I'm testing an iPad app thats receiving memory warnings 1,2 & 3.
I want to know the current used up memory from my app, which I think it has to be the "Live Bytes" column? which marks All Allocations to 2.42 MB which I think its low.
What do the other columns report? #Transitory, Overall Bytes ?
Also if my app uses only 3 MB of memory can it be killed if I get a memory level 3 warning without releasing?
Thank you.
Don't use the Object Allocations instrument for looking at your total memory usage. It does not display the true total memory size of your application, for reasons that I speculate about in my answer here.
Instead, pair Object Allocations with the Memory Monitor instrument, the latter of which will show the true total size of your application. I'm willing to bet that it's way larger than the 2.42 MB you're seeing in Object Allocations (for example, I had an application with 700k of memory usage according to ObjectAlloc, but its actual size was ~25 MB in memory). If you are receiving memory warnings on an iPad, your application is probably chewing up quite a bit of memory.
Object Allocations is handy for telling you what you have resident in memory, but it's not an accurate indicator of the size of those items. It's also a great tool for showing you steady increases in allocated objects by using the heap shot functionality (the "Mark Heap" button on the left-hand side of the instrument).
Your memory usage looks fine. Check to see which app is being sent the memory warnings, it is probably not your app assuming your app is not in the background. The only way you should be getting memory warnings is if the app is in the background and another app needs more memory.
When I was looking at logs I noticed other apps were getting them while my app was running, other apps such as Mail or navigation apps (Navigon) do run in the background and will cause memory pressure. You might get a memory warning but should not be terminated.
For a description of the memory columns see Explanation of Live Bytes & Overall Bytes.
As #Brad points out use the memory monitor tool as well.