Today, in the course of training, it was also mentioned that the analysis should be specific to the code. If the thinking direction is correct, for Java applications and C/C++ applications, it is also a few commands can jump to the code line. If you can read the stack. So I’ve been drawing this kind of thinking diagram as I’ve been lecturing.

In performance analysis, there are also tools available for C/C++ applications.

Today we’ll look at a simple C code example to see how to do these steps. I saw a sample code on the Internet, which saved me from writing it myself. I’m just going to compile it. Now let’s look at the operation.

[root@7dgroup Sample6]# gcc -o test6 -g test6.c

Remember to add the -g parameter when compiling to generate debugging information.

[root@7dgroup Sample6]# ./test6

Up and running:

[root@7dgroup Sample6]# ./test6

The return value: 3

The return value of 5

The return value: 5

The return value of 7

The return value: 7

The return value of 9

The execution process produces this data. Also look at top.

See 31356 this process has consumed CPU. Because this process is very simple, I won’t go down to the thread level here. Just hit the stack.

For complex applications, a further refinement of this step is to print thread-level state. You can use top-h, pidstat, or attach to threaddump using the debug tool. Just choose the way you like.

Gstack prints the stack directly.

[root@7dgroup ~]# gstack 31356

#0 0x00000000004005ed in function2 (input=963) at test6.c:4

#1 0x000000000040065b in function1 (a=9, b=10) at test6.c:21

#2 0x00000000004006e8 in main () at test6.c:39

Of course you can also pstack to print the stack (the PID has changed since I re-ran it).

[root@7dgroup ~]# pstack 31438

#0 0x0000000000400620 in function3 (input=3524) at test6.c:14

#1 0x000000000040067e in function1 (a=5, b=6) at test6.c:25

#2 0x00000000004006e8 in main () at test6.c:39

As can be seen from the stack information, there is only one thread and the call relation is:

The first printed stack is: 39 lines -> 21 lines -> 4 lines

The second printed stack is: 39 lines -> 25 lines -> 14

(Because it’s the same file, I’ll just write the line number).

This allows you to analyze from CPU to specific lines of code in C/C++ applications.

Again, the integrity of your analytical thinking is very important. You have to know what data you want to see before you know what tools to use to do it. Knowing the tools is nothing, but understanding the principles and being able to understand them is really something.

Some people might say, I don’t even know how to use the tools, how to know what data to look at. A seemingly paradoxical problem is actually lack of experience and need to learn more basic knowledge.

For example, if you know the analysis process running the Java language on Linux, the other analysis processes are similar, but the tools are different. This is not to say that only the analysis of Linux running Java, change to HPunix+C/C++ there is no idea.

It’s like elementary school math: there are four trees in a row, so how many trees are there in four rows? 16 tree! But replace a tree with a telephone pole and someone won’t.