Gprof Use and introduction

I. Introduction of GPROF

Gprof is the GNU Profiler tool. You can display the "flat profile" that the program runs, including the number of calls per function, and the processor time consumed by each function. You can also display the call graph, including the call relationships for functions, how much time each function call takes. You can also display the source code of the note, which is a copy of the program's source codes, marking the number of executions of each line of code in the program. Second, gprof function:

Printing out the elapsed time of each function in a program can help programmers find the most time-consuming functions in many functions.

Generating a function call relationship at runtime, including the number of calls, can help the programmer to analyze the program's running flow. With the function of the call relationship, which will allow developers to greatly improve productivity, do not bother to find a little bit of the program's running process, which may not be obvious to the small program, but for tens of thousands of, hundreds of thousands of code of the project, the efficiency is beyond doubt. And this feature for the maintenance of old code or analysis of open source that is quite tempting, with the call graph, the program's operating framework has a general understanding of the program's "skeleton", analysis it will not be so dazed, especially to their unfamiliar code and open source. Crap not much to say, let's start our analysis journey. Three, Gprof realization principle:

by compiling and linking your program (using-PG compile and link options), GCC adds a name of Mcount (or "_mcount", or "__mcount", depending on the compiler or operating system) to each function in your application function, which means that every function in your application calls Mcount, and Mcount saves a function call graph in memory and finds the address of the child function and parent function in the form of the function call stack. This call graph also holds all the information about the call time, the number of calls, and so on for the function.

After the program finishes running, a gmon.out file is generated under the path of the program exit. This file is the monitoring data that is recorded and saved. This data can be interpreted by means of gprof or graphical kprof of the command line, and the performance of the program is analyzed.

In addition, if you want to see the profiling of the library function, you need to compile and then add "-lc_p" compilation parameters instead of "-LC" compilation parameters, so that the program will link LIBC_P.A Library, can produce the profiling information of the library function. If you want to perform a row of profiling, you also need to include the "-G" compilation parameter. Iv. Scope of application of Gprof

Gprof can be used to analyze the number of function calls at runtime, time-consuming and so on, can conveniently help us to locate the bottleneck of the system, but also let us know that the location of the program to optimize the performance of the greatest possible result. Gprof optimization is especially suitable for CPU, memory-intensive application modules . v. Installation and use of Gprof

At present, most of our Linux hosts are installed with Gprof, detailed parameters, etc. can be viewed through the man gprof. It is important to point out that, at present, our online gprof support for multithreading is not good, the direct call can only get the main thread of the relevant call situation. According to the relevant information, the original because gprof use ITIMER_PROF signal, in multi-threaded, only the main thread to respond to the signal. To do this, some additional work is needed. Using the provided gprof-helper.c, compile it to the so library with the command: Gcc-shared-fpicgprof-helper.c-o GPROF-HELPER.SO-LPTHREAD-LDL

The purpose of this library is actually to implement a pthread_create hook program, so that when we call the Pthread_create function, we invoke the Pthread_create function provided in this library, so that we can get the information about the statistics runtime in the multi-threaded case.

In actual use, the method is relatively simple, in our own program's makefile file, plus the compiled option-PG, and add that dynamic link library. such as Gcc-pg Imbs_main.cpp. /gprof-helper.so$ (INCLUDE) $ (ldflags) $ (ldlibs).

This will generate a a.out file after compiling. This file is the executable file that contains the relevant statistical functions, and the program that we compile normally is completely consistent with the external behavior.

Reference: Http://blog.csdn.net/baqiao10/articles/443495.aspx

After the program runs and "normal" exits, a gmon.out file is generated, which is the runtime statistics file. Use the command gprof-ba.out gmon.out to output the information we readable in the end. This information can be used as a basis for our optimization.

Note: The above mentioned "normal" exit means that the program is in accordance with its own operating logic normal exit, if the direct killall-9 is not able to obtain statistical results. And our usual program is in the loop for a long time, so, the actual use of the corresponding Sigterm signal method, using Killall-s 15, send sigterm signal to the program, the program will have a corresponding function to capture the signal, after capturing the signal, set an exit mark, This allows the program to exit normally after a complete work has been done in accordance with the established logic.

This leads to another problem, in fact, we are now online program, restart the program, usually use Killall-9 to stop the original program. This is actually a big risk, for example, if the program is executed with some persistent operations, such as writing disk, while the write disk operation is done many times, such as writing data first, and then write the index, which should be a logical atomic operation, then the randomness of killall-9 may destroy its atomicity, This results in potential data inconsistencies, such as the existence of inconsistencies in the data that we commonly use in transfer. Although the probability of occurrence is not very high, but the long-term accumulation of this inconsistency will be gradually reflected.

vi. Basic usage of gprof:

1. Compile and link your application using the-PG option.
2. Execute your application so that it runs and generates a data file for Gprof analysis (default is Gmon.out).
3. Use the GPROF program to analyze the data generated by your application, for example: Gprof a.out gmon.out.

Example

Gcc-wall-pg-o testtest.c//program file name test.c compile-time use –PG

We can now run test again and use the test data we used earlier. When we run this time, the test run's profiling data is collected and saved in the ' gmon.out ' file, and we can see the results by running ' gprof test '.

./test

Gproftest vii. Information generated by Gprof

% The percentage of the total running time of the
Time program used by the This function.
function usage time as a percentage of all time.
Cumulative a running sumof the number of seconds accounted
seconds for by this function and those listed above it.
The time that the function and the above functions accumulate execution.
Self the number of seconds accounted
seconds function alone. The major sort for this
Listing.