gprof的替代品
其他程序与gprof有什么相同之处？
Valgrind有一个指令计数分析器，带有一个非常好的名为KCacheGrind的可视化工具。 正如Mike Dunlavey所建议的那样，Valgrind计算了一个程序在堆栈上运行的部分指令，尽管我很抱歉地说它在互相递归的情况下似乎变得混乱。 但是，可视化器在gprof之前非常好，光年也很好。
由于历史原因， gprof （阅读论文）存在。 如果你认为它会帮助你发现性能问题，它从来没有被广告过。 以下是该报告所说的内容：
该配置文件可用于比较和评估各种实施的成本。
它并没有说它可以用来识别要评估的各种实现，但它确实意味着它可以在特殊情况下：
特别是如果程序的一小部分被发现主宰它的执行时间。
那些没有如此本地化的问题呢？ 这些不重要吗？ 不要把期望放在从未声称过的gprof上。 它只是一个测量工具，并且只是CPU绑定操作。
试试这个。
这是一个44倍加速的例子。
这是一个730倍的加速。
这是一个8分钟的视频演示。
以下是对统计数据的解释。
这是对批评的回答。
关于程序有一个简单的观察。 在给定的执行过程中，每条指令都负责整个时间的一小部分（尤其是call指令），因为如果它不在那里，时间将不会被使用。 在那段时间里，指令在堆栈**上。 当明白这一点时，你可以看到 -
gprof体现了关于表现的某些神话，例如：
程序计数器采样是有用的。
它只有在你有一个不必要的热点瓶颈时才有用，比如大量标量值的冒泡排序。 例如，只要您将其更改为使用字符串比较进行排序，它仍然是一个瓶颈，但程序计数器采样不会看到它，因为现在热点位于字符串比较中。 另一方面，如果要对扩展程序计数器（调用堆栈）进行采样，则清楚地显示调用字符串比较的点，排序循环。 事实上， gprof是一种试图弥补纯电脑采样限制的尝试。
定时功能比捕获耗时的代码行更重要。
这个神话的原因是gprof无法捕获堆栈样本，所以它代替函数，计数它们的调用，并尝试捕获调用图。 但是，一旦确定了代价高昂的功能，您仍然需要查看其中负责时间的行。 如果有堆栈样本，你不需要看，这些线将在样本上。 （一个典型的函数可能有100 - 1000条指令，函数调用是1条指令，因此定位代价昂贵的调用的精确度要高出2-3个数量级。）
通话图很重要。
您需要了解程序究竟是不是在那里度过它的时间，但为什么 。 当它花费时间在一个函数中时，堆栈中的每一行代码都会在推理链中给出一个链接，以说明为什么它在那里。 如果你只能看到部分堆栈，你只能看到部分原因，所以你不能确定是否真的有必要。 通话图告诉你什么？ 每个弧段告诉你一些函数A正在调用一些函数B的一小部分时间。 即使A只有一个这样的代码行调用B，该行只会给出一小部分原因。 如果你足够幸运，也许这条线有一个不好的原因。 通常情况下，你需要看到多条同时发现的线路，如果它存在的话找到一个不好的原因。 如果A在多个地方呼叫B，那么它告诉你更少。
递归是一个棘手的混淆问题。
这只是因为gprof和其他分析人员认为需要生成一个调用图，然后将时间归入节点。 如果有一个样本是堆栈的，那么样本上出现的每一行代码的时间成本就是一个非常简单的数字 - 它所在样本的比例。 如果存在递归，则给定的行可能会在样本上出现多次。 不管。 假设每Nms采样一次，并且该行出现在它们的F％上（单独或不单独）。 如果这条线可以不花时间（例如删除它或绕过它），那么这些样本会消失，时间会减少F％。
时间测量的准确性（以及因此大量的样本）是重要的。
想一想吧。 如果一行代码在5个样本中有3个样本，那么如果您可以像灯泡一样拍摄出来，那么使用时间将大约减少60％。 现在，你知道，如果你采取了不同的5个样本，你可能只看过2次，或多达4个。所以60％的测量更像是40％到80％的一般范围。 如果只有40％，你会说这个问题不值得修复吗？ 那么，当你真正想要找到问题时，什么时间点准确？ 500或5000个样本会以更高的精度测量问题，但不会更准确地发现它。
计数语句或函数调用是有用的。
假设你知道一个函数被称为1000次。 你能从中了解到它花费了多少时间？ 您还需要知道平均运行需要多长时间，然后乘以计数，然后除以总时间。 平均调用时间可能会从几纳秒到几秒不等，所以单凭数量并不能说明多少。 如果有堆栈样本，例程或任何语句的成本只是它所在样本的一小部分。 如果日常工作或声明可以毫不费力地完成，那么这部分时间原则上可以节省下来，因此这与性能最直接的关系。
当阻塞时不需要采样
这个神话的原因有两个：1）程序在等待时PC采样毫无意义; 2）对时序准确性的关注。 但是，对于（1）该程序可能正在等待它所要求的某些内容，例如文件I / O，您需要知道哪些信息以及哪些堆栈示例显示。 （当然要排除的样品，同时等待用户输入）。对于（2）如果该程序正在等待仅仅是因为与其他进程竞争的，而它的运行可能会发生在一个相当随机的方式。 因此，虽然程序可能需要更长的时间，但对于重要的统计信息（即语句在堆栈中的时间百分比）没有太大影响。
“自我时间”很重要
自我时间只有在功能级别而不是线路级别测量时才有意义，并且您认为在辨别功能时间是否进入纯粹的本地计算与所调用的例程中需要帮助。 如果在行级进行汇总，如果行在堆栈的末尾，则表示自我时间，否则表示包含时间。 无论哪种方式，它所花费的是堆栈样本的百分比，以便在任何情况下都能为您找到它。
样品必须以高频率拍摄
这来自于性能问题可能是快速行动的想法，并且样本必须频繁才能实现。 但是，如果问题是成本，20％，也就是说，出的10秒（或其他）的总行驶时间，然后在总时间每个样品将如果出现问题有击中它，不管有20％的几率在这样一个单一的片段
.....XXXXXXXX...........................
.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^ （20个样品，4次命中）
或者像这样的许多小片段
X...X...XX.X.........X.....X....X.....
.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^ （20个样品，3次点击）
无论采用哪种方式，无论采取多少样本，或者有多少样本，命中次数平均约为1/5。 （平均值= 20 * 0.2 = 4。标准偏差= +/- sqrt（20 * 0.2 * 0.8）= 1.8）
你正在努力寻找瓶颈
仿佛只有一个。 考虑以下执行时间表： vxvWvzvWvxvWvYvWvxvWv.vWvxvWvYvW
它由真正有用的工作组成，代表着. 。 vWxYz性能问题vWxYz取1/2，1 / 4,1 / 8,1 / 16,1 / vWxYz的时间。 抽样很容易找到v 。 它被删除，离开
xWzWxWYWxW.WxWYW
现在该程序需要运行一半的时间，现在W需要一半的时间，并且很容易找到。 它被删除，离开
xzxYx.xY
这个过程继续下去，每次都去除最大的百分比性能问题，直到找不到任何可移除的东西。 现在唯一执行的是. ，它在原始程序使用的1/32时间内执行。 这是放大效应，通过消除任何问题使得余数更大，因为分母减少了。
另一个关键点是必须找到每一个问题 - 缺少5个。任何未找到并修复的问题都会严重降低最终加速比。 只是发现一些，但不是全部，不够“不够好”。
补充：我只想指出gprof受欢迎的一个原因 - 它正在被教导，大概是因为它是免费的，易于教学，并且已经存在很长时间了。 快速谷歌搜索找到一些教授它（或看起来）的学术机构：
伯克利BU科罗拉多州克莱姆森公爵阿勒姆FSU印第安纳州麻省理工学院MSU ncsa.illinois北卡罗莱纳州立大学纽约大学瓯普林斯顿PSU斯坦福加州大学圣地亚哥分校UMD密西根大学犹他州utexas UTK wustl
**除了要求完成工作的其他方式外，不要留下跟踪原因的跟踪，例如通过邮件发布。
由于我没有在这里看到关于perf一切，这是一个在Linux上分析内核和用户应用程序的相对较新的工具，我决定添加这些信息。
首先 - 这是一个关于使用perf Linux分析的教程
如果您的Linux内核版本大于2.6.32，则可以使用perf如果旧版本则可以使用oprofile 。 这两个程序都不需要你来测试你的程序（如gprof要求）。 但是为了在perf正确获取调用图，您需要使用-fno-omit-frame-pointer构建程序。 例如： g++ -fno-omit-frame-pointer -O2 main.cpp 。
您可以通过perf top查看您的应用程序的“实时”分析：
sudo perf top -p `pidof a.out` -K
或者，您可以记录正在运行的应用程序的性能数据并在之后进行分析：
1）记录性能数据：
perf record -p `pidof a.out`
或记录10秒钟：
perf record -p `pidof a.out` sleep 10
或用调用图（）记录
perf record -g -p `pidof a.out`
2）分析记录的数据
perf report --stdio
perf report --stdio --sort=dso -g none
perf report --stdio -g none
perf report --stdio -g
或者，您可以记录应用程序的性能数据并在之后分析它们，只需以这种方式启动应用程序并等待它退出：
perf record ./a.out
这是分析测试程序的一个例子
测试程序在文件main.cpp中（我将把main.cpp放在消息的底部）：
我用这种方式编译它：
g++ -m64 -fno-omit-frame-pointer -g main.cpp -L. -ltcmalloc_minimal -o my_test
我使用libmalloc_minimial.so因为它是使用-fno-omit-frame-pointer编译的，而libc malloc似乎是在没有此选项的情况下编译的。 然后我运行我的测试程序
./my_test 100000000
然后我记录正在运行的进程的性能数据：
perf record -g -p `pidof my_test` -o ./my_test.perf.data sleep 30
然后我分析每个模块的负载：
perf报告--stdio -g none --sort comm，dso -i ./my_test.perf.data
# Overhead Command Shared Object
# ........ ....... ............................
#
70.06% my_test my_test
28.33% my_test libtcmalloc_minimal.so.0.1.0
1.61% my_test [kernel.kallsyms]
然后分析每个功能的负载：
perf报告--stdio -g none -i ./my_test.perf.data | C ++ FILT
# Overhead Command Shared Object Symbol
# ........ ....... ............................ ...........................
#
29.30% my_test my_test [.] f2(long)
29.14% my_test my_test [.] f1(long)
15.17% my_test libtcmalloc_minimal.so.0.1.0 [.] operator new(unsigned long)
13.16% my_test libtcmalloc_minimal.so.0.1.0 [.] operator delete(void*)
9.44% my_test my_test [.] process_request(long)
1.01% my_test my_test [.] operator delete(void*)@plt
0.97% my_test my_test [.] operator new(unsigned long)@plt
0.20% my_test my_test [.] main
0.19% my_test [kernel.kallsyms] [k] apic_timer_interrupt
0.16% my_test [kernel.kallsyms] [k] _spin_lock
0.13% my_test [kernel.kallsyms] [k] native_write_msr_safe
and so on ...
然后调用链分析：
perf报告--stdio -g graph -i ./my_test.perf.data | C ++ FILT
# Overhead Command Shared Object Symbol
# ........ ....... ............................ ...........................
#
29.30% my_test my_test [.] f2(long)
|
--- f2(long)
|
--29.01%-- process_request(long)
main
__libc_start_main
29.14% my_test my_test [.] f1(long)
|
--- f1(long)
|
|--15.05%-- process_request(long)
| main
| __libc_start_main
|
--13.79%-- f2(long)
process_request(long)
main
__libc_start_main
15.17% my_test libtcmalloc_minimal.so.0.1.0 [.] operator new(unsigned long)
|
--- operator new(unsigned long)
|
|--11.44%-- f1(long)
| |
| |--5.75%-- process_request(long)
| | main
| | __libc_start_main
| |
| --5.69%-- f2(long)
| process_request(long)
| main
| __libc_start_main
|
--3.01%-- process_request(long)
main
__libc_start_main
13.16% my_test libtcmalloc_minimal.so.0.1.0 [.] operator delete(void*)
|
--- operator delete(void*)
|
|--9.13%-- f1(long)
| |
| |--4.63%-- f2(long)
| | process_request(long)
| | main
| | __libc_start_main
| |
| --4.51%-- process_request(long)
| main
| __libc_start_main
|
|--3.05%-- process_request(long)
| main
| __libc_start_main
|
--0.80%-- f2(long)
process_request(long)
main
__libc_start_main
9.44% my_test my_test [.] process_request(long)
|
--- process_request(long)
|
--9.39%-- main
__libc_start_main
1.01% my_test my_test [.] operator delete(void*)@plt
|
--- operator delete(void*)@plt
0.97% my_test my_test [.] operator new(unsigned long)@plt
|
--- operator new(unsigned long)@plt
0.20% my_test my_test [.] main
0.19% my_test [kernel.kallsyms] [k] apic_timer_interrupt
0.16% my_test [kernel.kallsyms] [k] _spin_lock
and so on ...
所以在这一点上，你知道你的程序在哪里花费时间。
这是测试的main.cpp：
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
time_t f1(time_t time_value)
{
for (int j =0; j < 10; ++j) {
++time_value;
if (j%5 == 0) {
double *p = new double;
delete p;
}
}
return time_value;
}
time_t f2(time_t time_value)
{
for (int j =0; j < 40; ++j) {
++time_value;
}
time_value=f1(time_value);
return time_value;
}
time_t process_request(time_t time_value)
{
for (int j =0; j < 10; ++j) {
int *p = new int;
delete p;
for (int m =0; m < 10; ++m) {
++time_value;
}
}
for (int i =0; i < 10; ++i) {
time_value=f1(time_value);
time_value=f2(time_value);
}
return time_value;
}
int main(int argc, char* argv2[])
{
int number_loops = argc > 1 ? atoi(argv2[1]) : 1;
time_t time_value = time(0);
printf("number loops %dn", number_loops);
printf("time_value: %dn", time_value );
for (int i =0; i < number_loops; ++i) {
time_value = process_request(time_value);
}
printf("time_value: %ldn", time_value );
return 0;
}