XCode 5 Debug Navigator Memory disagrees with Instruments

Question

I'm working on my first ARC & Core Data project, basing this stage on Xcode's (Universal) Master-Detail template. I note that Xcode5 has a memory display in the Debug Navigator but when using it find its graph bears few similarities with mem usage displayed in Instruments when running a Leaks&Allocations trace. I've done the Instruments tracing with the Simulator (simulating both iPhone & iPad - in case the 'unloading' of the detail View with the latter makes a difference) and on an iPad2 & an iPodTouch. The results are broadly the same:

iPhone 6.1 simulator

1. Generation A--------1.13 MB
2. Generation B--------397.70 KB
3. Generation C--------76.96 KB
4. Generation D--------11.70 KB
5. Generation E--------1.56 KB
6. Generation F--------3.48 KB

an overall growth of c30%

where Generation A shows the growth to the loading of the Master table, and each successive Generation the growth after the Detail view has been visited and interacted with (entailing the fetching of NSManagedObjects and the creation of NSObjects, respectively). The growth trend with the other devices was broadly similar (with the Generation A growth being iPad sim:1.42; iPad2:1.57; iPodTouch:0.94 but tailing off similarly).

According to the Debug Navigator, however, the total usage at each point comes out at:

iPhone 6.1 Debug Navigator

1. Generation A--------4.2 MB
2. Generation B--------6.9 MB--growth 2.7
3. Generation C--------7.1 MB--growth 0.2
4. Generation D--------7.8 MB--growth 0.7
5. Generation E--------8.0 MB--growth 0.2
6. Generation F--------8.4 MB--growth 0.4
   an overall growth of 100%!

Referring to other similar questions, I don't have Zombies enabled. Have others seen such discrepancies? Am I right in being inclined to trust Instruments over the Debug Navigator's summary figure?

PS. Debug Navigator's summary figure doesn't seem to be available when running the real devices (both on versions of iOS5). Is this normal?

Answer 1

This may not be a very good answer for you, but it is my justification for this issue with the research that I have done.

The debug navigator shows the same things as the "Activity Monitor" instrument. It is not showing current allocated memory by your app, it's showing current memory allowed to your app by the OS.

Say I create a for loop to create lots of objects in memory, but then I delete half of them because they don't fit my search criteria (bad coding, I know, but hypothetically here). The OS would get a request from your app for the full memory to create all of the objects, but after the loop when you check your allocations in instruments it shows only the saved objects because garbage collection took out the deleted ones. The OS may or may not know about the garbage collection events, but it doesn't take the memory that it just gave you away. I'm not sure of the overhead of giving/taking available memory from your app, but I'm sure they take that into account. I've noticed that if I leave my app alone long enough the OS takes some of the memory I'm not using back.

Just think of the debugging memory information as your app's full memory allotted by the OS. You may not be using all of it, but the OS gave it to you anyway (for one reason or another). This number will increase based on your app's requests/use. It will decrease due to Memory Pressure warnings or inactivity that the OS thinks it can safely recover the memory from you. It will likely never match the Instruments allocated memory information because there is always transient memory used in applications that needs to be allocated somewhere even for a short time.

Again, this is my conclusion based on when I was wondering the same thing you are. Hope it helps a little.