IOS Performance Tuning series: Use Time Profiler to discover performance bottlenecks and tune profiler

IOS Performance Tuning series: Use Time Profiler to discover performance bottlenecks and tune profiler

Hardware wide: The fifth article in the IOS Performance Tuning series, which is expected to be updated continuously over 20 articles.

The last four articles focus on memory and Analyze memory leakage, zombie objects, and memory allocation. This article introduces the use of Time Profiler to start a true "performance" Tuning journey.

Time Profiler also has the Leaks and Allocations tools introduced earlier. It is also known as the Three life-saving tools of Instruments. It is the first three tools to be used when an application encounters problems.

Time Profiler helps us analyze the code execution Time, find out the cause of program slowdown, and tell us "where is the Time ?".

Before using Time Profiler, let's take a look at the original performance analysis method.

Original Performance Analysis Method

 

This analysis method is estimated to be the first thought of by many developers. Write a unit test and record the time at the beginning and end.

Sample Code:

NSDate *stDate = [NSDate date];for(int i = 0; i < 999; i++){// do something   }NSDate *endDate = [NSDate date];NSLog(@"time:%f", [endDate timeIntervalSinceDate:stDate]);

By calculating the time difference, you can calculate the time consumed in the middle. By using this method, you can analyze code that may encounter performance bottlenecks in part.

The disadvantages of this method are as follows:

1. The test efficiency is too low, and many performance bottlenecks are hard to predict. It needs to be removed from the upper layer to the lower layer;

2. Unable to test the UI rendering efficiency and identify the interface performance bottleneck;

3. NSLog analysis is not accurate enough. It is possible that the performance of the Development device on the simulator is fast, and the performance bottleneck cannot be clearly distinguished.

This is also the advantage of using the Time Profiler tool to identify performance bottlenecks with high efficiency.

Performance Analysis Using Time Profiler

 

Time Profiler Analysis Principle: It tracks the stack information of each thread at a fixed interval, and calculates how long a method has been executed by comparing the stack status between intervals, and obtain an approximate value. In fact, it is basically the same as our original analysis method, except that it counts the time consumed by each method.

Like other tools using Instruments, click the Product menu Profile of XCode to start Instruments:

Select the Time Profiler tool to start the test. The simulator and Time Profiler recording are automatically started.

First, perform some App operations to allow Time Profiler to collect enough data, especially those that have performance bottlenecks.

The panel marked by 4, 5, and 6 should be noted:

4 is the extended panel, used to trace and display the stack; 5 is the detailed Panel, where you can see the cpu running time consumption; 6 is the option panel, it can be used to set the runtime parameters of Time Profiler.

You can view the most time-consuming operations on the application in the Detail Panel and view them row by row:

The black icon is the prompt given by Time Profiler. If there may be performance bottlenecks, You can gradually expand down to find the root cause.

For example, through analysis, we found that the [CMTool getNewsTimeFromLong] Time Formatting Function may need to be optimized.

Of course, here is just an example. The performance tuning should first proceed from the overall order to the detailed order in order to receive the most obvious effect.

Time Profiler parameter settings

 

The meanings of these options are as follows:

Separate by Thread: Each Thread should be considered separately. Only in this way can you find the "heavy" threads that occupy a lot of CPU

Invert Call Tree: The trace Stack from the top down, which means that the method in the table you see will have been sampled from 0th frames, which is usually what you want, only in this way can you see the method with the deepest CPU charges. that is to say, after selecting this option in FuncA {FunB {FunC}, the stack displays the deepest C in the call Level in the outermost form with a C-> B-A.

Hide Missing Symbols: If dSYM cannot find your app or system framework, you cannot see the method name in the table but only hexadecimal values. If this line is checked, these Symbols can be hidden to simplify data

Hide System Libraries

Show Obj-C Only: Only Show oc code. If your program is a program like OpenGl, do not select the lateral check because it may be C ++

Flatten Recursion: recursive function. Each stack traces an entry.

Top Functions: the sum of the time a function spends in the function and the total time it takes to call the function. Therefore, if function A calls function B, it is very useful to report the time spent by function A plus the time spent by function B, because it allows you to pick the maximum time number each time you go down to the call stack, and return to zero in your most time-consuming method.

The above parameters are reasonably set in practice, and there is not much skill, that is, data hiding and display make us focus more on the data we want to find.

The world's applications are never broken! Especially for mobile apps, pay more attention to user experience and response speed.

 

Record, for better yourself!