C ++分析技术概述
在这个答案中，我将使用几种不同的工具来分析一些非常简单的测试程序，以具体比较这些工具的工作方式。
以下测试程序非常简单，并且可以执行以下操作：
main通话fast和maybe_slow3次，一个maybe_slow呼叫正在缓慢
慢速调用的maybe_slow时间长10倍，并且如果考虑到对子函数的调用，则占主导地位的运行时common。理想情况下，性能分析工具可以将我们指向特定的慢速通话。
fast和maybe_slowcall 两者都common占了程序执行的大部分
程序界面为：
./main.out [n [seed]]
并且该程序O(n^2)总共执行循环。seed只是为了获得不同的输出而不影响运行时间。
main.c
#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
uint64_t __attribute__ ((noinline)) common(uint64_t n, uint64_t seed) {
for (uint64_t i = 0; i < n; ++i) {
seed = (seed * seed) - (3 * seed) + 1;
}
return seed;
}
uint64_t __attribute__ ((noinline)) fast(uint64_t n, uint64_t seed) {
uint64_t max = (n / 10) + 1;
for (uint64_t i = 0; i < max; ++i) {
seed = common(n, (seed * seed) - (3 * seed) + 1);
}
return seed;
}
uint64_t __attribute__ ((noinline)) maybe_slow(uint64_t n, uint64_t seed, int is_slow) {
uint64_t max = n;
if (is_slow) {
max *= 10;
}
for (uint64_t i = 0; i < max; ++i) {
seed = common(n, (seed * seed) - (3 * seed) + 1);
}
return seed;
}
int main(int argc, char **argv) {
uint64_t n, seed;
if (argc > 1) {
n = strtoll(argv[1], NULL, 0);
} else {
n = 1;
}
if (argc > 2) {
seed = strtoll(argv[2], NULL, 0);
} else {
seed = 0;
}
seed += maybe_slow(n, seed, 0);
seed += fast(n, seed);
seed += maybe_slow(n, seed, 1);
seed += fast(n, seed);
seed += maybe_slow(n, seed, 0);
seed += fast(n, seed);
printf("%" PRIX64 "\n", seed);
return EXIT_SUCCESS;
}
gprof
gprof要求使用工具重新编译该软件，并且它还与该工具一起使用采样方法。因此，它在准确性（采样并不总是完全准确并且可以跳过函数）与执行速度（仪表和采样是相对较快的技术，不会大大减慢执行速度）之间取得平衡。
gprof内置在GCC / binutils中，因此我们要做的就是编译-pg启用gprof 的选项。然后，我们使用大小CLI参数正常运行该程序，该运行会产生几秒钟的合理持续时间（10000）：
gcc -pg -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
time ./main.out 10000
出于教育原因，我们还将在未启用优化的情况下进行运行。请注意，这实际上没有用，因为您通常只关心优化已优化程序的性能：
gcc -pg -ggdb3 -O0 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
./main.out 10000
首先，time告诉我们带和不带执行时间-pg是相同的，这很棒：不放慢速度！但是，我已经看到复杂软件的速度下降了2到3倍，例如此票证所示。
由于我们使用编译-pg，因此运行程序将生成一个gmon.out包含概要分析数据的文件文件。
我们可以gprof2dot按以下要求以图形方式观察该文件：是否可以获取gprof结果的图形表示？
sudo apt install graphviz
python3 -m pip install --user gprof2dot
gprof main.out > main.gprof
gprof2dot < main.gprof | dot -Tsvg -o output.svg
在此，该gprof工具读取gmon.out跟踪信息，并在中生成人类可读的报告main.gprof，gprof2dot然后读取该报告以生成图形。
gprof2dot的来源位于：https : //github.com/jrfonseca/gprof2dot
我们观察到以下-O0运行情况：
和-O3运行：
该-O0输出几乎是不言自明的。例如，它显示这3个maybe_slow调用及其子调用占据了总运行时的97.56％，尽管不带子进程的执行maybe_slow占了总执行时间的0.00％，即，几乎在该函数上花费的所有时间都花在了儿童电话。
TODO：即使我可以在GDB中看到它，为什么输出中也main缺少-O3它bt？我认为这是因为Gprof不仅基于编译工具，而且基于采样，而且-O3 main速度太快，没有样本，因此我认为这是因为GProf输出缺少功能。
我选择SVG输出而不是PNG，因为SVG可通过Ctrl + F搜索，并且文件大小可以小10倍左右。此外，对于复杂的软件，生成的图像的宽度和高度可能非常庞大，有成千上万的像素，而eog在这种情况下，GNOME 3.28.1会针对PNG进行修正，而SVG会由我的浏览器自动打开。虽然gimp 2.8运作良好，但另请参阅：
但是即使那样，您仍然会拖拉图像很多，以找到所需的内容，例如，从这张票证中获取的“真实”软件示例中的图像：
将所有这些细小的未分类的意大利细面条线互相重叠，您能轻松找到最关键的呼叫堆栈吗？dot我确定可能会有更好的选择，但是我现在不想去那里。我们真正需要的是一个合适的专用查看器，但我还没有找到一个：
但是，您可以使用颜色图稍微缓解这些问题。例如，在上一个巨大的图像上，当我做出出色的推论时，我终于设法找到了左边的关键路径，即绿色紧随红色之后，最后是越来越深的蓝色。
另外，我们也可以观察gprof以前保存在以下位置的内置binutils工具的文本输出：
cat main.gprof
默认情况下，这会产生一个非常冗长的输出，解释输出数据的含义。由于我无法解释得更好，因此我会让您自己阅读。
一旦理解了数据输出格式，就可以减少冗长程度以仅显示数据，而无需使用带有以下-b选项的教程：
gprof -b main.out
在我们的示例中，输出为-O0：
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
100.35 3.67 3.67 123003 0.00 0.00 common
0.00 3.67 0.00 3 0.00 0.03 fast
0.00 3.67 0.00 3 0.00 1.19 maybe_slow
Call graph
granularity: each sample hit covers 2 byte(s) for 0.27% of 3.67 seconds
index % time self children called name
0.09 0.00 3003/123003 fast [4]
3.58 0.00 120000/123003 maybe_slow [3]
[1] 100.0 3.67 0.00 123003 common [1]
-----------------------------------------------
<spontaneous>
[2] 100.0 0.00 3.67 main [2]
0.00 3.58 3/3 maybe_slow [3]
0.00 0.09 3/3 fast [4]
-----------------------------------------------
0.00 3.58 3/3 main [2]
[3] 97.6 0.00 3.58 3 maybe_slow [3]
3.58 0.00 120000/123003 common [1]
-----------------------------------------------
0.00 0.09 3/3 main [2]
[4] 2.4 0.00 0.09 3 fast [4]
0.09 0.00 3003/123003 common [1]
-----------------------------------------------
Index by function name
[1] common [4] fast [3] maybe_slow
和为-O3：
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls us/call us/call name
100.52 1.84 1.84 123003 14.96 14.96 common
Call graph
granularity: each sample hit covers 2 byte(s) for 0.54% of 1.84 seconds
index % time self children called name
0.04 0.00 3003/123003 fast [3]
1.79 0.00 120000/123003 maybe_slow [2]
[1] 100.0 1.84 0.00 123003 common [1]
-----------------------------------------------
<spontaneous>
[2] 97.6 0.00 1.79 maybe_slow [2]
1.79 0.00 120000/123003 common [1]
-----------------------------------------------
<spontaneous>
[3] 2.4 0.00 0.04 fast [3]
0.04 0.00 3003/123003 common [1]
-----------------------------------------------
Index by function name
[1] common
作为每个部分的快速摘要，例如：
0.00 3.58 3/3 main [2]
[3] 97.6 0.00 3.58 3 maybe_slow [3]
3.58 0.00 120000/123003 common [1]
以左缩进（maybe_flow）的函数为中心。[3]是该函数的ID。函数的上方是调用方，而调用方的下方。
对于-O3，请参见此处，就像图形输出中一样，maybe_slow并且fast没有已知的父级，这就是文档所说的<spontaneous>意思。
我不确定是否有很好的方法用gprof进行逐行分析：gprof 在特定代码行上花费的时间
valgrind callgrind
valgrind通过valgrind虚拟机运行程序。这使得配置文件非常准确，但是也会导致程序运行速度大大降低。我之前在以下地方也提到过kcachegrind：用于获取图形函数的代码调用图的工具
callgrind是valgrind的代码分析工具，kcachegrind是可以可视化cachegrind输出的KDE程序。
首先，我们必须删除该-pg标志以返回正常编译，否则运行实际上会因失败Profiling timer expired，并且是的，这很常见，以至于我遇到了这个问题，并且存在堆栈溢出问题。
因此，我们编译并运行为：
sudo apt install kcachegrind valgrind
gcc -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
time valgrind --tool=callgrind valgrind --dump-instr=yes \
--collect-jumps=yes ./main.out 10000
我--dump-instr=yes --collect-jumps=yes之所以启用，是因为这还会转储信息，使我们能够以相对较小的增加的开销成本查看每条装配线的性能明细。
即时，time告诉我们该程序需要29.5秒的时间来执行，因此在此示例中，速度降低了大约15倍。显然，这种放缓将成为较大工作负载的严重限制。在这里提到的“实际软件示例” 中，我观察到速度降低了80倍。
在本例中，运行会生成一个名为callgrind.out.<pid>例如的配置文件数据文件callgrind.out.8554。我们通过以下方式查看该文件：
kcachegrind callgrind.out.8554
该图显示了一个GUI，其中包含类似于文本gprof输出的数据：
另外，如果我们在右下角的“调用图”选项卡上，我们将看到一个调用图，可以通过右键单击将其导出以获取以下图像，并获得不合理数量的白色边框：-)
我认为fast没有显示在该图上，因为kcachegrind必须简化了可视化，因为该调用占用的时间太少，这很可能是您在实际程序上想要的行为。右键单击菜单有一些设置可以控制何时剔除此类节点，但是经过快速尝试后，我无法让它显示出如此短的调用。如果单击fast左侧窗口，它的确会显示带有的调用图fast，因此实际上已捕获了该堆栈。尚未找到一种显示完整图形调用图的方法：使callgrind显示kcachegrind调用图中的所有函数调用
在复杂的C ++软件上使用TODO时，我看到一些type类型的条目<cycle N>，例如<cycle 11>，我期望函数名称的位置，那是什么意思？我注意到有一个“循环检测”按钮可以将其打开和关闭，但这是什么意思呢？
perf 从 linux-tools
perf似乎专门使用Linux内核采样机制。这使得设置非常简单，但也不完全准确。
sudo apt install linux-tools
time perf record -g ./main.out 10000
这增加了0.2s的执行时间，因此我们可以按时使用，但是在common使用键盘右箭头扩展节点之后，我仍然没有看到太多兴趣：
Samples: 7K of event 'cycles:uppp', Event count (approx.): 6228527608
Children Self Command Shared Object Symbol
- 99.98% 99.88% main.out main.out [.] common
common
0.11% 0.11% main.out [kernel] [k] 0xffffffff8a6009e7
0.01% 0.01% main.out [kernel] [k] 0xffffffff8a600158
0.01% 0.00% main.out [unknown] [k] 0x0000000000000040
0.01% 0.00% main.out ld-2.27.so [.] _dl_sysdep_start
0.01% 0.00% main.out ld-2.27.so [.] dl_main
0.01% 0.00% main.out ld-2.27.so [.] mprotect
0.01% 0.00% main.out ld-2.27.so [.] _dl_map_object
0.01% 0.00% main.out ld-2.27.so [.] _xstat
0.00% 0.00% main.out ld-2.27.so [.] __GI___tunables_init
0.00% 0.00% main.out [unknown] [.] 0x2f3d4f4944555453
0.00% 0.00% main.out [unknown] [.] 0x00007fff3cfc57ac
0.00% 0.00% main.out ld-2.27.so [.] _start
因此，然后我尝试对-O0程序进行基准测试，以查看是否显示任何内容，直到现在，我才终于看到调用图：
Samples: 15K of event 'cycles:uppp', Event count (approx.): 12438962281
Children Self Command Shared Object Symbol
+ 99.99% 0.00% main.out [unknown] [.] 0x04be258d4c544155
+ 99.99% 0.00% main.out libc-2.27.so [.] __libc_start_main
- 99.99% 0.00% main.out main.out [.] main
- main
- 97.54% maybe_slow
common
- 2.45% fast
common
+ 99.96% 99.85% main.out main.out [.] common
+ 97.54% 0.03% main.out main.out [.] maybe_slow
+ 2.45% 0.00% main.out main.out [.] fast
0.11% 0.11% main.out [kernel] [k] 0xffffffff8a6009e7
0.00% 0.00% main.out [unknown] [k] 0x0000000000000040
0.00% 0.00% main.out ld-2.27.so [.] _dl_sysdep_start
0.00% 0.00% main.out ld-2.27.so [.] dl_main
0.00% 0.00% main.out ld-2.27.so [.] _dl_lookup_symbol_x
0.00% 0.00% main.out [kernel] [k] 0xffffffff8a600158
0.00% 0.00% main.out ld-2.27.so [.] mmap64
0.00% 0.00% main.out ld-2.27.so [.] _dl_map_object
0.00% 0.00% main.out ld-2.27.so [.] __GI___tunables_init
0.00% 0.00% main.out [unknown] [.] 0x552e53555f6e653d
0.00% 0.00% main.out [unknown] [.] 0x00007ffe1cf20fdb
0.00% 0.00% main.out ld-2.27.so [.] _start
TODO：-O3处决发生了什么？难道仅仅是maybe_slow和fast是太快了，并没有得到任何的样本？-O3在需要较长时间执行的大型程序上，它是否能很好地工作？我错过了一些CLI选项吗？我发现-F要控制赫兹采样频率，但是我将其调到默认允许的最大值-F 39500（可以通过增大sudo），但仍然看不到清晰的声音。
一件很酷的事情perf是Brendan Gregg的FlameGraph工具，该工具以非常简洁的方式显示了调用堆栈的时间，使您可以快速查看大调用。该工具可在：https://github.com/brendangregg/FlameGraph和还提到了他PERF教程：http://www.brendangregg.com/perf.html#FlameGraphs当我跑perf没有sudo我ERROR: No stack counts found这样的现在我将使用sudo：
git clone https://github.com/brendangregg/FlameGraph
sudo perf record -F 99 -g -o perf_with_stack.data ./main.out 10000
sudo perf script -i perf_with_stack.data | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > flamegraph.svg
但是在这样一个简单的程序中，输出不是很容易理解，因为我们既不容易看到maybe_slow也不fast在该图中看到：
在更复杂的示例中，可以清楚地看到图形的含义：
TODO [unknown]在该示例中有一个功能日志，为什么？
另一个值得一看的perf GUI界面包括：
gperftools
以前称为“ Google Performance Tools”，来源：https : //github.com/gperftools/gperftools基于示例。
首先使用以下命令安装gperftools：
sudo apt install google-perftools
然后，我们可以通过两种方式启用gperftools CPU事件探查器：在运行时或在构建时。
在运行时，我们必须将设置LD_PRELOAD为指向libprofiler.so，您可以在中找到它locate libprofiler.so，例如在我的系统上：
gcc -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libprofiler.so \
CPUPROFILE=prof.out ./main.out 10000
另外，我们可以在链接时构建库，LD_PRELOAD在运行时分发过程：
gcc -Wl,--no-as-needed,-lprofiler,--as-needed -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
CPUPROFILE=prof.out ./main.out 10000
另请参阅：gperftools-未转储配置文件
到目前为止，查看此数据的最好方法是使pprof输出与kcachegrind用作输入的格式相同（是，Valgrind-project-viewer-tool），然后使用kcachegrind来查看：
google-pprof --callgrind main.out prof.out > callgrind.out
kcachegrind callgrind.out
使用这些方法之一运行后，我们将获得一个prof.out概要文件数据文件作为输出。我们可以使用SVG以图形方式查看该文件：
google-pprof --web main.out prof.out
与其他工具一样，它提供了一个熟悉的调用图，但单位是采样数而不是秒。
另外，我们还可以通过以下方式获取一些文本数据：
google-pprof --text main.out prof.out
这使：
Using local file main.out.
Using local file prof.out.
Total: 187 samples
187 100.0% 100.0% 187 100.0% common
0 0.0% 100.0% 187 100.0% __libc_start_main
0 0.0% 100.0% 187 100.0% _start
0 0.0% 100.0% 4 2.1% fast
0 0.0% 100.0% 187 100.0% main
0 0.0% 100.0% 183 97.9% maybe_slow
另请参阅：如何使用Google Perf工具
已在Ubuntu 18.04，gprof2dot 2019.11.30，valgrind 3.13.0，perf 4.15.18，Linux内核4.15.0，FLameGraph 1a0dc6985aad06e76857cf2a354bd5ba0c9ce96b，gperftools 2.5-2中进行了测试。
