0

I am using Allocations Profiling template for an iOS Instrumentation. I created an extension to UIView class, that takes a snapshot for a view that is not added to the view hierarchy. I want to double check how much memory does my new method consume. I have found out that my new method allocates 288 Bytes from the heap as indicated in the following image. enter image description here

Then I navigated to the corresponding method and I found out that there is a big memory amount as expected. Have a look on the following image. enter image description here

My questions are:

  1. Why could not I see these huge number in the heap?
  2. Where is this huge memory allocated from?
  3. Is there a specific detail view (other than Call Tree) that reflects this hug number?

Please note that I am not asking about what is the best way to take a snapshot for a view. I am already familiar with Apple method snapshotView. I am doing this exercise just to test my understanding for the Memory Usage in iOS.

Wael Showair
  • 3,092
  • 2
  • 22
  • 29

1 Answers1

3

A couple of thoughts:

  1. Be careful when filtering the results of the call tree. You could have accidentally pruned out the routine with which the profiler associated the memory. Try (a) selecting the range of the graph that has the allocation in question (to reduce the amount of noise in the results); (b) removing the filter and then (c) expand the tree at that point where you see the large memory jump:

    look for jump

  2. Personally, I often find it easier to flip the call tree and hide system libraries:

    enter image description here

  3. Alternatively, you can also go to the "Statistics" of "Allocations" and find the big allocation:

    enter image description here

    You can then drill into that:

    enter image description here

    And then by clicking on the "Extended Detail" panel on the right, jump to the code in question:

    enter image description here

  4. If you want, another way to find allocations in Xcode 8 is to turn on the "Malloc Stack" option on your scheme and then use the "Debug Memory Graph" option as outlined in https://stackoverflow.com/a/30993476/1271826.

    For example, I used the "Debug Memory Graph", found the CG Raster Data, and I can see the object graph for this 10mb image, as well as can see the stack where this was allocated in the "Extended Details" panel on the right:

    enter image description here

Community
  • 1
  • 1
Rob
  • 415,655
  • 72
  • 787
  • 1,044
  • Thanks Rob for your answer but i am not sure how can I relate your answer to my 3 related questions? – Wael Showair Oct 02 '16 at 01:33
  • Your first question was "why am I not seeing the allocation" in my call tree, to which my answer was "(a) don't filter the call tree like you did; and (b) make sure to select range around the allocation in question". Your second question was "where was this big allocation from", which no one can answer for you, short of showing you different ways of identifying allocations (and I showed you three different ways to accomplish this). Your third question was what other mechanisms are there for finding allocations, and again, I showed you a number of alternatives. I don't know what else I can do. – Rob Oct 02 '16 at 03:58
  • Thanks Rob for your answer but the huge memory does not appear without any filter and that is hence your answer for a does not help me. as for b, you did not answer it. finally for c, i really appreciate your important alternatives but none of them reveal this huge memory. Hence I will be waiting for any other inputs in the community who might help me in answering these questions. Thanks again. – Wael Showair Oct 03 '16 at 17:51