Why is there a difference between the declared use of application memory using Activity Monitor and the distribution tool

Question

I ran into a rather strange problem.

Application ~ 80.Mb

Testing on a simulator using Allocations Instrument shows me that about 30 MB is currently used, but when testing on iPod 4g using Activity Monitor, “Used physical memory - 133 MB” and “Free physical memory memory 77 MB” are displayed.

Due to memory warnings, my app is constantly crashing.

What is the difference between the physical memory used in ActivityMonitor and Allocations Instrument?

I used to trust Allocations Instrument because when I released the objects, the amount of used memory decreased, but in the ActivityMonitor the amount of USED memory increases and decreases in a strange way, which does not depend on what I do. So help me understand, because I think the allocated memory is the same as the memory used, or am I wrong?

Edit: It seems I understood how the data is displayed in the ActivityMonitor. But the problem persists. In ActivityMonitor there is a column below the graph. There I found my application. And there the memory only increases.

No leaks 100%

Answer 1

Activity monitoring is useless for development / debugging purposes. AM is only useful when you no longer have the tools and you see that RPRVT grows significantly over time. Even then, this is just a symptom and may not indicate a real problem.

AM is a generalization of a set of different numbers related to memory. This is a very crude number. The Allocations tool summarizes the exact set of distributions in your application (which on Mac OS X can include both GC and non-GC distributions). Decrease the allocation and overall memory usage tends to decrease.

Note that a system that is not under memory pressure often does not ask applications to return memory. That is, you may not see a drop in the numbers of Activity Monitors.

Also note that “100% no leaks” is only about 10% of the total effort to reduce memory usage. Your application is being thrown out due to egregious memory consumption. This is either due to an architectural problem when your application's algorithms use a lot of memory or because your application allocates and leaves memory. Abandoned memory may not appear as a leak; if you have, say, a cache entry in which duplicate elements of an element are cached again and again but never retrieved, your memory usage will increase to failure, but leaks will not contain leaks.

A leak is just an object for which there are no viable links. A flexible link object may still be an effective leak!

A heapshot analysis is brutally effective in discussing this issue.