I am using instrument "Allocations" to monitor the app's memory. The vm tracker statistics puzzled me. Why there is so much dirty memory(for my app, reach 32M), I googled about this and knew that the dirty memory should be clear first when app received memory warning in background mode.
Could you tell me about the meaning of vm checker statistics? And how can I handle the dirties:VM_ALLOCATE, Core Animation.
Thanks in advance!
There is often very little you can do about VM usage directly; much of that will be due to use of various system APIs, etc...
Your time will be far more productively spent by focusing on the objects in the Allocations instrument itself and work towards both eliminating any leaks (accretion, too, not just leaks) and reducing allocation bandwidth.
Related
First let me start off by saying I do not believe I am leaking, but I could be wrong. My issue is that at after my app is done loading I have about 10 - 20 mb of Live bytes according to object alloc, which I am fine with. However, according to activity monitor my process allocation is about 70 - 80 mb, which needless to say is a bit high. To make matters worse when I go on to load the next screen of my app I need to pull more data to build it, which then sends my process allocation up to 100 mb+ or so, need less to say this is much to high and the next action after this causes my app to crash due to low memory warnings. Is there anyway to reduce the process allocation memory?
Belief can sometimes be validated with cold hard data. Have you tried using Leaks? Allocations is another helpful memory profiling performance tool provided by Instruments. The way to reduce memory allocation is to not use as much. ;-)
What are you allocating that takes up 100+ MB? Images? Video?
The question is, are you releasing memory when you're done with it. Instruments can help you answer that question. If you show some code, the community can try to help you troubleshoot as well.
Best regards.
What are the best practices, tricks, and tutorials for using XCode's performance tools, such as the Leak Monitor and the CPU sampler, for someone trying to debug and enhance performance of an iPhone application?
Thanks!
It depends entirely on the application and on what you are trying to do. Are you trying to optimize the whole application or are you focused on a particular problem area? Are you trying to reduce memory usage, reduce CPU usage, and/or make the app more responsive?
Before you start the performance analysis, use the static analyzer to analyze your code. It will often find memory management problems that would lead to leaks that would cause your app to potentially crash on the device.
Once all of the analyzer identified problems have been fixed, the best approach is to start by identifying perceived performance problems. That is, focus on performance problems that the user would notice. Then analyze those. If you can get away with it, do the analysis on the app running in the simulator as the turnaround time is faster.
If the problem is one of bloat, use Object Alloc and Leaks to figure out why.
If it is one of laggy/sluggish behavior, use the CPU tools to figure out where the cycles are going. Keep in mind, though, that sluggish behavior may not be because of CPU usage, but may be because the main event loop is blocked by something, most likely incorrect concurrency patterns. In that case, you'll see all samples on the main thread in some kind of a lock or wait function.
Beyond that, you'll need to identify specific scenarios to yield specific answers.
use instruments in that use
object allocation
activity monitor,
leaks
memoer monitor
and test your app
My app crashes after about 20 minutes with status 101 (Out of Memory, I believe)
Debugging using Instruments - ObjectAlloc and Leaks gives me no clues. The ObjectAlloc graph stays at a nice constant level of around 1 million bytes (1MB), as does the Net # of allocations. I have got rid of all leaks.
I thought it could be something to do with number of threads, but graphing these in ObjectAlloc also shows them to be constant.
Can anyone point me in the direction of another tool, or another avenue of investigation?
Fix everything Clang finds. LLVM Clang Static Analysis
Remember that objects allocated by the system (and that includes things like images and sounds) don't get tracked in Instruments (although the top level retain counts do, of course). So it's feasable that you're loading images, say, which won't contribute much to your memory usage as show, but can drain a lot of actual memory!
If none of this strikes any chords, you could try the subtractive debugging approach - (take a copy of your project) cut out chunks of functionality until the problem goes away or you get the smallest possible thing that reproduces it. That should at least help you to find where the bottleneck is. Admittedly this will be hard (a) because you'll have to wait 20 minutes or so every time you test (but if you make this a background procedure it's not so bad) and (b) because the nature of memory problems is that there may not be one single cause, but a critical mass of smaller causes.
Good luck!
My experiences with Object Alloc have not been that great. It does not always give you the actual memory used by your application.
Instead, use Object Alloc with Activity Monitor. Make sure you use the "Physical Memory Free" and "Physical Memory used" options in the activity monitor. That will tell you exactly how much memory your application is using.
What do you mean by "nice level". It does not rise over time, at all? How much memory total - it could just be the phone needs some memory for some other app and yours is a little too big to stay up.
The error code 101 means that iPhone OS force quit your app. If you're using UIImageViews in your application, be sure to manage the memory on them. I've found that once my application goes over 10/12 MB, the iPhone terminates it.
If you're not using any image views (or large images), then your backend code is eating up too much space.
All I can say is you need to look at your allocation more carefully and manage what views you keep in memory at any one time.
Run your application in Instruments (Run -> Start with Performamce Tool -> Leaks) to see where your memory is getting allocated.
Hope this helps!
I was curious, when one goes ahead and executes their code for leaks checking with Instruments -- is it prudent to hit all of the parts of the app manually to ensure memory leaks are occurring in that respective area? For instance, I believe I have some memory leaks in my application, deep within a UINavigationController tree. Do I go ahead and run the app checking for leaks, while manually drilling down on the iPhone to get to that part of the app? Is Instruments smart enough to find it on its own? What's the proper way of going about it?
Thanks for any insight!
No, Instruments just monitors the memory allocations of your code, it does not "go" anywhere, unless your app goes there. Actually a leak is nothing more than a piece of memory to that no reference exists anymore; thus it cannot be freed anymore, since how are you going to free it in the future if you cannot even reference to it any longer?
Instruments won't find all memory leaks that way, though. If you keep references to the memory, just never use them to free the memory, Instruments won't see this as a leak, because it cannot foresee if you are going to ever free it up in the future or not. As you still could free it up, it's not considered a leak. So if you have a memory issue, it might be beneficial to not just look for leaks, but also to monitor how much memory your application is "collecting" over the time. If this permanently rises even though it shouldn't, you might still have a leak, just none where you lose the references to the memory.
Typically, I would focus on the module suspected of causing the leaks and then widen the scope afterward. While I have not used Instruments on a Mac, I have used Purify and the native Windows heap tools to do memory leak tracing in Windows programs.
After you have identified the source of your major leak it's never a bad idea to run the program with varying test input and generally check the program for other leaks. Even small leaks with a particular set of data can lead to much larger leaks down the road.
I am working on a 2D iPhone game using OpenGL ES and I keep hitting the 24 MB memory limit – my application keeps crashing with the error code 101. I tried real hard to find where the memory goes, but the numbers in Instruments are still much bigger than what I would expect.
I ran the application with the Memory Monitor, Object Alloc, Leaks and OpenGL ES instruments. When the application gets loaded, free physical memory drops from 37 MB to 23 MB, the Object Alloc settles around 7 MB, Leaks show two or three leaks a few bytes in size, the Gart Object Size is about 5 MB and Memory Monitor says the application takes up about 14 MB of real memory. I am perplexed as where did the memory go – when I dig into the Object Allocations, most of the memory is in the textures, exactly as I would expect. But both my own texture allocation counter and the Gart Object Size agree that the textures should take up somewhere around 5 MB.
I am not aware of allocating anything else that would be worth mentioning, and the Object Alloc agrees. Where does the memory go? (I would be glad to supply more details if this is not enough.)
Update: I really tried to find where I could allocate so much memory, but with no results. What drives me wild is the difference between the Object Allocations (~7 MB) and real memory usage as shown by Memory Monitor (~14 MB). Even if there were huge leaks or huge chunks of memory I forget about, the should still show up in the Object Allocations, shouldn’t they?
I’ve already tried the usual suspects, ie. the UIImage with its caching, but that did not help. Is there a way to track memory usage “debugger-style”, line by line, watching each statement’s impact on memory usage?
What I have found so far:
I really am using that much memory. It is not easy to measure the real memory consumption, but after a lot of counting I think the memory consumption is really that high. My fault.
I found no easy way to measure the memory used. The Memory Monitor numbers are accurate (these are the numbers that really matter), but the Memory Monitor can’t tell you where exactly the memory goes. The Object Alloc tool is almost useless for tracking the real memory usage. When I create a texture, the allocated memory counter goes up for a while (reading the texture into the memory), then drops (passing the texture data to OpenGL, freeing). This is OK, but does not always happen – sometimes the memory usage stays high even after the texture has been passed on to OpenGL and freed from “my” memory. This means that the total amount of memory allocated as shown by the Object Alloc tool is smaller than the real total memory consumption, but bigger than the real consumption minus textures (real – textures < object alloc < real). Go figure.
I misread the Programming Guide. The memory limit of 24 MB applies to textures and surfaces, not the whole application. The actual red line lies a bit further, but I could not find any hard numbers. The consensus is that 25–30 MB is the ceiling.
When the system gets short on memory, it starts sending the memory warning. I have almost nothing to free, but other applications do release some memory back to the system, especially Safari (which seems to be caching the websites). When the free memory as shown in the Memory Monitor goes zero, the system starts killing.
I had to bite the bullet and rewrite some parts of the code to be more efficient on memory, but I am probably still pushing it. If I were to design another game, I would certainly think of some resource paging. With the current game it’s quite hard, because the thing is in motion all the time and loading the textures gets in the way, even if done in another thread. I would be much interested in how other people solve this issue.
Please note that these are just my views that do not have to be much accurate. If I find out something more to say on this topic, I will update the question. I’ll keep the question open in case somebody who understands the issue would care to answer, since these all are more workarounds and guesses than anything else.
I highly doubt this is a bug in Instruments.
First, read this blog post by Jeff Lamarche about openGL textures:
has a simple example of how to load
textures without causing leaks
gives understanding of how "small"
images, get once they are loaded
into openGL, actually use "a lot" of memory
Excerpt:
Textures, even if they're made from
compressed images, use a lot of your
application's memory heap because they
have to be expanded in memory to be
used. Every pixel takes up four bytes,
so forgetting to release your texture
image data can really eat up your
memory quickly.
Second, it is possible to debug texture memory with Instruments. There are two profiling configurations: OpenGL ES Analyzer and OpenGL ES Driver. You will need to run these on the device, as the simulator doesn't use OpenGL. Simply choose Product->Profile from XCode and look for these profiles once Instruments launches.
Armed with that knowledge, here is what I would do:
Check that you're not leaking memory -- this will obviously cause this problem.
Ensure your'e not accessing autoreleased memory -- common cause of crashes.
Create a separate test app and play with loading textures individually (and in combination) to find out what texture (or combination thereof) is causing the problem.
UPDATE: After thinking about your question, I've been reading Apple's OpenGL ES Programming Guide and it has very good information. Highly recommended!
One way is to start commenting out code and checking to see if the bug still happens. Yes it is tedious and elementary, but it might help if you knew where the bug was.
Where it is crashing is why it is crashing, etc.
Hrmm, that's not many details, but if leaks doesn't show you where the leaks are, there are two important options:
[i] Leaks missed a leak
[ii] The memory isn't actually being leaked
fixing [i] is quite hard, but as Eric Albert said filing a bug report with Apple will help. [ii] means that the memory you're using is still accessible somewhere, but perhaps you've forgotten about it. Are any lists growing, without throwing out old entries? Are any buffers being realloc()ed a lot?
For those seeing this after the year 2012:
The memory really loaded into device's physical memory is the Resident Memory in VM Tracker Instrument.
Allocation Instrument only marks the memory created by malloc/[NSObject alloc] and some framework buffer, for example, decompressed image bitmap is not included in Allocation Instrument but it always takes most of your memory.
Please Watch WWDC 2012 Session 242 iOS App Performance: Memory to get the information from Apple.
This doesn't specifically help you, but if you find that the memory tools don't provide all the data you need, please file a bug at bugreport.apple.com. Attach a copy of your app and a description of how the tools are falling short of your analysis and Apple will see if they can improve the tools. Thanks!