Why is there a difference between the reported memory usage of an app by Activity Monitor and the Allocations Instrument

Question

I am facing quite strange problem.

Application ~80.Mb

Testing on simulator using Allocations Instrument, shows me that currently is using about 30 Mb but when testing on iPod 4g using Activity Monitor shows "Physical Memory Used ~ 133Mb" and "Physical Memory Free ~ 77Mb"

Due to the memory warnings my app constantly crashes.

What is the difference between Physical Memory Used in ActivityMonitor and Allocations Instrument?

Earlier I have trusted Allocations Instrument because when I released objects the amount of memory used decreased, but in ActivityMonitor the amount of USED memory is increasing and decreasing in a strange way that does not depend on what I am doing. So, help me to understand, because I think the memory allocated is the same as memory used, or I am wrong?

Edit: Seems I understood the way the data is shown in activitymonitor. But the problem persists. In ActivityMonitor there is column below the graph. There I found my application. And there memory is only increasing.

There are no leaks 100%

Answer 1

Activity Monitor is useless for development/debugging purposes. AM is only useful if when you don't have Instruments running already & you see the RPRVT growing over time significantly. Even then, it is just a symptom and may not indicate a real problem.

AM is sort of summarizing a set of different memory related numbers. It is a very rough number. The Allocations instrument is summarizing exactly the set of allocations in your application (which, under Mac OS X, could include both GC and non-GC allocations). Reduce the allocations and the overall memory use will generally go down.

Note that a system not under memory pressure will often not request that applications give back memory. That is, you may not see a drop in Activity Monitors numbers.

Note also that "there are no leaks 100%" is only about 10% of the overall effort to reduce memory use. Your app is being jettisoned because of egregious memory consumption. That is either because of an architectural issue where your app's algorithms use way to much memory or because your app is allocating and abandoning memory. Abandoned memory may not show up as a leak; if you have, say, a write only cache where duplicates of an item are put into the cache over and over, but never retrieved, your memory use will grow to failure yet leaks will show no leaks.

A leak is merely an object for which there are no viable references. A viably referenced object may still effectively be a leak!

Heapshot analysis is brutally effective at sussing out this kind of problem.