iOS Testing with Instruments - Best Practices - ios

Since I'm developing iOS based applications, I'm also spending much time on getting started with testing applications and debugging performance issues.
After reading the instruments user guide, I'm now able to detect memory leaks, record the current memory size and cpu-usage and much more, which quiet helps a lot!
Now, in order to improve my testing strategy, I'm looking for a kind of bench mark values or standard values for the different instruments (such as cpu- usage, energy consumption, ...). You know what I mean? For example: I have a cpu-usage of 80% over a period of 10 seconds. Is that okay or should I think about performance optimization? Sure, in case of cpu-usage, it depends on the action that the app does over that period of time (e.g. reloading some data or something like that) but is there any rule of thumb or best practices for that?
I already did a research on the internet and only found a video of the iOS tech talk in london from Michael Jurewitz. In that talk, i figured out the following statements that are properly useful for me:
Activity Monitor: Can only be used to compare your app's resource usage to other apps
Allocations: A constantly growing allocations chart is obviously a bad sign for memory leaks. Allocations does not show the real memory size the app uses
VM Tracker: Show overall memory size; Rule of thumb: more than 100 MB dirty size of an app is far too much
...
Now I need some "rules of thumb", especially for the CPU Monitor (where is the boundary between good case and bad case?) and Energy Consumption (Level..?).
Do you have any tips for me or do you know some articles I can read through?
Thanks a lot!
Philipp

Related

How to know if I have to do memory profiling too?

I currently do CPU sampling of an ASP.NET Core application where I send huge number of requests(> 500K) to it. I see that the peak working set of the application is around ~300 MB which in my opinion is not huge considering the number of requests being made to the application. But what I have been observing is huge drop in requests per second when I enable certain pieces of functionality in my application.
Question:
Should I do memory profiling too? I ask this because even though the peak working set is ~300MB, there could be large number of short lived objects that could be created & collected by GC and since work by GC also counts as CPU, should I do memory profiling too to see if I allocate too much?
I will answer this question myself based on new information that I found out.
This is based on the tool PerfView, which provides information about GC and allocations.
When you open the GCStats view navigate the links to the process you care and you should see information like below:
Notice that view has the information has the % CPU Time spent Garbage Collecting. If you see this to be > 5% then it should be a cause of concern and you should start memory profiling.

Apple Instruments slows down app when analyzing memory allocations

When running my app in the simulator and analyzing its memory allocations using Instruments, the App runs very slow, it runs at less than 1/30 of its normal speed.
The app uses about 50 MB RAM and has approximately 900,000 life objects (according to Instruments).
Could this be the reason for the slow performance?
When running in the app on the device or in the simulator without using Instruments, it performs well (except the memory issue I am trying to debug).
Do you have any idea on how to solve this issue?
Did you encounter slow performance using the Memory Allocation
instruments?
Would you consider having more than 900,000 life
objects "concerning"?
Considering your Analyzer performance issue
In your specific case monitoring the app over a long period of time will not be necessary, as you reach the state of high memory consumption very soon. You could simply stop recording at this point. Then you won't have problems navigating through the different views and statistics to find the cause of the memory issue.
Analyzing the memory issue
Slowing down is normal. 1/30 sounds quite alarming.
You probably should track how the amount of life objects and the memory usage change while you use the app.
It is difficult to decide if a certain amount of life objects at a specific point in time is critical (though 900,000 seems very high).
In general: if life objects and memory usage grow continuously and don't shrink, that is a bad sign.
If you take a look Statistics -> Object Summary (Screenshot), Live Bytes should be a lot smaller than Overall Bytes and the amount of #Living objects should be a lot smaller than the amount of #Transitory objects.
The second thing you can look at, is the Call Tree view.
It gives you a nice overview of which parts of the application are responsible for reserving large amount of memory:
Possible solutions
Once you detect the parts of your code that are responsible for reserving the large memory amount you can look for retain-cycles or you could try to use more autorelease pools in that spot.
Check that you have enough available disk space. I had 8gb left and it seems like that was too little. Instruments was extreeemely slow. Used a minute just to start and didn't quite get around at all.
I cleared out more disk space and then it suddenly went back to being fast as before.

windows phone diagnostics logging

is it possible to get memory and CPU usage in windows phone (sdk 7.1) application?
what would be the best way to retrieve that data from the application for further analysis?
Try the Windows Phone Performance Analysis tool, it allows you to profile CPU usage, memory usage and record garbage collection:
If you're looking to analyze performance as well, take a look at the Frame Rate counters (these are enabled by default when you are debugging your app)
You'll want to keep your FPS high, and your screen fill rate low (anything above 3 or so is cause for deep concern, since it means your screen is being redrawn 3x for every frame; not the best thing for performance)
Jeff Wilcox has a good summary on this too which is worth reading.

Any good Profiler with CPU details for ASP.net MVC 3 Web application?

What are some good Profiler for asp.net mvc3 application with CPU usage details?
I have tried New Relic, Slimtune and Mini Profiler. All of them just provide what process is taking longer, but none of them actually give any insights as what is causing high cpu?
All of the above profiler did good job and we improved the process and now it no longer take long time to respond, it loads page in 300-500 ms, but now we're more concerned on CPU usage. Because sometimes application takes lots of high CPU very randomly, and we are trying to find what is causing this behaviour.
High CPU spikes can be for a number of reasons.
First thing I would do is determine if the 'random' high CPU is due to a Generation 2 garbage collections.
ASP.NET Case Study: High CPU in GC - Large objects and high allocation rates
Investigating Memory Issues
Memory Performance Counters
Garbage Collection and Performance
There are quite a few built-in performance counters that might be helpful:
ASP.NET Performance Monitoring, and When to Alert Administrators
Sam Saffron (one of the StackoverFlow authors by the way) has created a great command-line tool a while ago, but unfortunately has abandoned it.
A friend of mine forked the code to make it work in 2015:
https://github.com/jitbit/cpu-analyzer
(the page has a link to Sam's post explaining how to use it)

ios instruments vm tracker IOKit insane residence size

I've just been analyzing an ipad app I'm developing using Instruments. In particular I was interested in the memory usage, as I have been receiving some memory warnings.
First of all the Activity monitor reports overall some 40MB of memory used just after starting the application. This really seams like a lot to me. Especially as after the startup nothing really fancy is going on.
So I have been analyzing the app in the VM tracker.
First of all can somebody explain how to interpret the dirty memory? I mean the ipad doesn't really have virtual memory, in the sense that there is no swapping etc.
Ok the really weird thing is that I have some 40 MB of dirty memory, that is resident! Some 38MB are listed under IOKit. Under IOKit there is no further information, what that actually means.
So what exactly does IOKit do?
What could be causing this insane those huge values?
Any kind of hint is appreciated! :)
Try Heapshot Analysis, bbum has a great tutorial here.
Basically you take a Heapshot, run some procedure, take another Heapshot for several iterations. This will help find memory that lost but not a leak. I use this method often,
I have used Heapshot many times to great advantage, many thanks to bum.
What is dirty memory?
According to this session.
memory written by an app
all heap allocations
decoded image buffers
VM profile shows some info of the dirty memory
like dirty memory size. They are anonymous.
vmmap --summary App.memgraph
In this session, this Apple dev uses heap to get more info about the object sizes.
heap App.memgraph

Resources