Ambiguities in using Instruments for iOS Development

6
votes

I am Profiling an Application with Instruments. The profiling is done using Allocations Tool in two ways:

  1. By choosing Directly the Allocations when I run the App for Profiling
  2. By Choosing Leaks when I run the App for Profiling.

In both the cases , I had Allocations tool enabled for testing. But surprisingly , I had two different kind of Out put for Allocations at these instances.

Are they supposed to behave differently? or this is a problem with Instruments.

The time I Profile the with Leaks Tool:

In Allocations Graph: enter image description here 1. I get lot of Peaks in Graph, The Live bytes and overall bytes are same. 2. I get the Black flags (I think it alarms about memory warning) after 1 minutes usage. Then after a set of flags appearing, my App Crashes. (This happens at times, even when directly run the App in Device)

The time I Profile the with Allocation Tool:

In Allocations Graph: enter image description here 1. I do not get peaks often as it was in the above case. The Live bytes was always way less than Overall bytes. 2. I have used for over 20 minutes and never got Black flags.

One fact I came to know is that, when Live bytes and overall bytes are equal, the NSZombieEnabled could be enabled.

Have any of you ever encountered this problem.

UPDATE 1:

I faced another problem with first case. Whenever I profiled after a short duration (compared to profiling in second case), the app got lots of Black Flags and my App Crashed. (Due to Memory warning)

And when I tried the similar step by step use of Application my Application did not crash and got no flags.

Why this discrepancy?

2
iosmemoryinstruments

2 Answers

9
votes

In the first case, you are only tracking live allocations because the "Leaks" template configures the Allocations instrument that way. In the second, you are tracking both live and deallocated allocations. (As CocoaFu said).

Both are useful, but for slightly different reasons.

Only tracking live allocations (in combination with Heapshot Analysis, typically), is a great way to analyze permanent heap growth in your application. Once you know what is sticking around forever, you can figure out why and see if there are ways to optimize it away.

Tracking all allocations, alive and dead, is a very effective means of tracking allocation bandwidth. You can sort by overall bytes and start with the largest #. Have a look at all the points of allocation (click the little arrow next to the label in the Category of the selected row), and see where all the allocations are coming from.

For example, your graph shows that there are 1.27MB of 14 byte allocations -- 9218 allocations -- over that period of time. All have been free()d [good!], but that still represents a bunch of work to allocate, fill with data (presumably), and free each one of those. It may be a problem, maybe not.

(To put this in perspective, I used this technique to optimize an application. By merely focusing on reducing the # of transient -- short lived -- allocations, I was able to make the primary algorithms of the application 5x faster and reduce memory use by 85%. Turns out the app was copying strings many, many, times.)

Not sure why your app crashed as you described. Since it is a memory warning, you should see what is most frequently allocated.

Keep in mind that if you have zombie detection enabled, that takes a lot of additional memory.

2
votes

Depending on the way Allocations is instantiated there are different options. Check the options by clicking the "i" symbol in the Allocations tile.

Yes, I find this annoying also.