Performance testing-Functional performance Analysis Chapter

Performance test-function Performance Analysis Chapter -quantify

After stress testing with Act (application Center test), how to locate the module that found the performance problem, and discover the performance bottleneck, requires you to understand a performance analysis tool, the quantify in the Rational test suite. Quantify is a Vb,vc,java function-level performance analysis tool, it can automatically detect the impact of program performance bottlenecks, while providing graphical analysis tables to help programmers perform performance analysis and optimization.

In the process of performance optimization, some programmers often rely on experience to analyze their written code, to find performance bottlenecks, this will face two problems:

1, the programmer found the performance bottleneck of the code is likely to think that they are not reasonable algorithm, but in the process of optimization, we all know that performance optimization is not a reasonable optimization algorithm, but the main optimization takes up the longest time function;

2. In a large project, how to find performance bottlenecks in tens of thousands of code is one of the most headaches, if you do not understand the project that is more difficult to do;

So how to efficiently raise the problem, rather than through the inspection of the code to find the problem is the key, and quantify is a weapon such as the Divine Soldier.

Quantify has the following features:

1, the impact on the current development is particularly small, but also integrated in a number of common development tools, greatly enhance the ease of use, such as visual Studio;

2, the performance of the display in a graphical manner, you can very directly understand the bottleneck of performance;

3, without the source code can be most of the system performance analysis;

4, the display of the function of the information is very detailed, including the number of calls, time, etc., there are related to the call relationship;

5, in the testing function, the performance analysis, no need for additional auxiliary code;

The following is an example to detail how to use quantify for performance analysis and find problems, here I use cppunit write a test case, used to test a piece of performance problems of the code (code will not be sent out, hehe), Mainly through it to let you know quantify is a very simple tool:

L The performance test only needs to run the compiled program, as shown in figure:

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml"/><?xml:namespace prefix = o ns = "Urn:schemas-mi" Crosoft-com:office:office "/>

As shown in Figure 1

The resulting results are shown in Figure 2, which is particularly simple:

As shown in Figure 2

However, to quickly analyze, there are mainly the following points, first of all, to introduce a few knowledge, is to understand, if you need detailed understanding, these are far from enough:

1. Function time: The duration of the functions itself, which does not contain the time of the child function;

2. F+d Time (function+descendants): The function itself and the function call of the child function when the execution of;

3. Calls: The number of times the function is invoked during execution;

4. F time (%): is the function itself (does not contain child functions) to occupy the entire system uptime percentage;

5. F+d time (%): is the function itself to consume time and the percentage of the whole call time of the child function;

6 avg F (time): mainly refers to the average operation of the function;

7. Min F (time): The minimum run-time in the process of function call;

8. Max F (time): The maximum runtime in the function call process;

9. Module: It is called by that DLL;

In the performance analysis process, one of the principles is to optimize the longest-consuming function or the longest-growing function, so I usually focus on function time and F times (%) to sort this out to find performance problems, and of course, modules related to their own systems, as shown in figure:

As shown in Figure 3

Here you can see the system is related to their own system output function, its calls times are very high, while taking up the time and the percentage is also very much, oh, then you can know this is related to the system performance bottlenecks, my code is written in this, hehe.

Demo Performance Test

void cmabstring::D emoper ()

{

cout<< "Begin performance/n";

int result = 0;

for (int j=0;j<1000;j++)

{

cout<< "This is performance test/n";

}

cout<< "End performance/n";

}

Of course you can also figure out how your function is made up of those child functions, as shown in the diagram:

As shown in Figure 4

From here you can see cmabstring::D emoper the child function called below is Osteam, the number of calls is 1002, the performance is 99.8%, and the upper-level function, called cmabstring, is also visible::D Emoper function Mathtest::testdemper, through the graph can see the call relationship between functions, at the same time can be in depth tracking its call relationship and performance, or special convenience, but to note that It is possible that the number of child function calls and the performance of the function can be even more than the upper-level functions, why, mainly shown here is the number of calls to the entire process, that is, may be called in other places this call this function, so this is a very normal phenomenon. However, if the system is not familiar or not familiar with the tool will point to the dizzy, I have been dizzy for many times, haha. The above example is very simple, that is, the cycle takes up time.

The above analysis just navigates to the function, but can you navigate to the source level? The answer is yes. As long as the source code, you can analyze from the source level, you can clearly see each piece of code execution time, and function execution time, through this method you can quickly locate the problem, the following figure:

Figure 5

Here Linetime is the line itself execution time, line+d is the line execution time and subtree execution time, through the source level analysis can see this code performance bottleneck in the For loop, of course, not necessarily can optimize, but if can optimize will enhance the most obvious.

But the performance problem is not only the code [bad writing, there are some database problems or network transmission and so on, when you find that if you call the database method problems or network library problems, you can turn to the network library or database analysis.

Quantify there are other convenient places, such as the analysis of the results of the preservation is very convenient, supporting a variety of languages, of course, the tool is not omnipotent, the most important is the human factors, hope to be able to improve your performance analysis through the tool ability.