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.
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.
My questions are:
Why could not I see these huge number in the heap?
Where is this huge memory allocated from?
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.
A couple of thoughts:
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:
Personally, I often find it easier to flip the call tree and hide system libraries:
Alternatively, you can also go to the "Statistics" of "Allocations" and find the big allocation:
You can then drill into that:
And then by clicking on the "Extended Detail" panel on the right, jump to the code in question:
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:
Related
I can't find how to determine how much memory is in use by individual objects.
Using Xcode's visual memory debugger, the memory shown on the right side (circled red) is not how much memory the object is actually using.
Xcode allocation instruments seems to only show the entire heap and memory used by individual allocations, not objects as a whole.
Am I missing something? Is there anyway to see how much aggregated memory is used by individual objects?
The title pretty much says it. I am writing an algorithm (and right now porting it into nasm) that would need to allocate lots (upwards of 8gb) of ram (as a severe tradeoff for cpu usage). On every iteration it stores an int onto the stack (for output and later usage). Then, periodically it could free a set of values but only from the bottom of the stack. Could this be done by simply decrementing the stack base (rbp)?
A stack is a stack. You can push and pop values on the top but nothing more. You cannot deallocate anything from it in any other way.
Changing RBP doesn't do anything, it is just a helper register to use for the current stack frame. RSP shows the current top of the stack and moving that changes where the next value will be stored to or retrieved from within the stack. So you can drop a bunch of values from the top if needed, but not from the bottom.
If you have a need to temporarily store values and later release them then a circular buffer or blocks of regular memory would be a much better suited for that.
I have a collection view that displays 3 images, two labels, and 1 attributed string(strings are of different colors and font sizes and values are not unique for every cell). One of the images is coming from the web and I used AFnetworking to do the downloading and caching. The collection view displays 15 cells simultaneously.
When I scroll I can only achieve 25 frames/sec.
Below are the things I did:
-Processing of data were done ahead and cached to objects
-Image and views are opaque
-Cells and views are reused
I have done all the optimizations I know but I can't achieve at least 55 frames/sec.
If you could share other techniques to speed up the re-use of cells.
I was even thinking of pre-rendering the subviews off screen and cache it somewhere but I am not sure how it is done.
When I run the app on the iPhone it is fast since it only shows at least four cells at a time.
The first thing you need to do is fire up instruments and find out if you're CPU-bound (computation or regular I/O is a bottleneck) or GPU-bound (the graphics card is struggling). . depending on which of these is the issue the solution varies.
Here's a video tutorial that shows how to do this (among other things) . . This one is from Sean Woodhouse # Itty Bitty Apps (they make the fine Reveal tool).
NB: In the context of performance tuning we usually talk about being I/O bound or CPU bound as separate concerns, however I've grouped them together here meaning "due to either slow computation or I/O data is not getting to the graphics card fast enough". . if this is indeed the problem, then the next step is to find out whether it is indeed related to waiting on I/O or the CPU is maxed-out.
Instruments can be really confusing at first, but the above videos helped me to harness its power.
And here's another great tutorial from Anthony Egerton.
What is the size of the image that you use?
One of the optimization technique which would work is that
Resize the image so that it matches the size of the view you are displaying.
I have been tested my app with instruments allocations and get this picture:
Like graphic shows, my app work normally, but is it normally value in overall bytes? And I'm worry about "#Allocations (Net/Overall)", because it's color is red.What is it mean (red color)
Red is the total (Overall) allocations made and deallocated during all your App's runtime.
Purple (really thin bar over the red one) are the allocated and not yet deallocated objects.
I would say that you don't need to worry too much about it, specially for internal objects or Malloc, and focus indeed on higher level objects such as views and controllers.
Also if you click on the Allocations tool's i you can choose to ignore CF (Core Foundation) or Malloc allocations, which I often do as you don't normally deal directly/don't have control over those allocations.
Again as you improve your higher level objects allocations you'll be indirectly improving those underlying allocations as well.
This topic was mentioned in my CS data structure class, but I didn't quit followed it. So wondering if anyone can spend a little time explain to me how that will work with sequential allocation in memory. It will be very helpful with a graph or some illustration that can help me understand it.
Also I am wondering if this can happen to two queues.
Thank you
I am assuming sequential allocation used here means a block of memory, without gaps.
One possibility is that this can be something like a deque (double ended queue), except this would be a double ended stack. So for example, you allocate a block of sequential memory that has enough memory for N elements, you would have a pointer to the "top" of the first stack, which would start at the first element and grow to the right. You would also have a pointer to the "top" of the second stack, which would start at the last element and grow left. If the two "tops" cross each-other, its time to "grow" the memory; reallocate and copy one or both stacks to the new spot. Thus each of the stacks can grow until both of their sizes together surpasses N.
Illustration (from here, a page discussing using such data structures as allocators):
With respect to queues, yes you create two queues out of this block, but it will potentially have an extra hole/gap, as the bottoms of the queues can move up (away from the ends). A possible solution to this would be, instead of popping off the front, one could empty the front element, and swap with the back, while keeping pointers to the actual front and back.
Hardware call stacks always grow in the same direction, but you could have two software stacks growing from opposite ends of an allocation. This seems trivial and cute, so it may not be what you're talking about.