如何找到在Linux上运行的C++应用程序中运行缓慢的代码区域？
当前回答
使用Valgrind、callgrind和kcachegrind：
valgrind --tool=callgrind ./(Your binary)
生成callgrind.out.x。使用kcachegrind读取它。
使用gprof（add-pg）：
cc -o myprog myprog.c utils.c -g -pg
（对于多线程、函数指针不太好）
使用google perftools：
使用时间采样，可以发现I/O和CPU瓶颈。
英特尔VTune是最好的（出于教育目的免费）。
其他：AMD Codeanalysis（已被AMD CodeXL取代）、OProfile、“perf”工具（apt-get-install-linux工具）
其他回答
使用Valgrind、callgrind和kcachegrind：
valgrind --tool=callgrind ./(Your binary)
生成callgrind.out.x。使用kcachegrind读取它。
使用gprof（add-pg）：
cc -o myprog myprog.c utils.c -g -pg
（对于多线程、函数指针不太好）
使用google perftools：
使用时间采样，可以发现I/O和CPU瓶颈。
英特尔VTune是最好的（出于教育目的免费）。
其他：AMD Codeanalysis（已被AMD CodeXL取代）、OProfile、“perf”工具（apt-get-install-linux工具）
还值得一提的是
HPC工具包(http://hpctoolkit.org/)-开源，适用于并行程序，并具有一个GUI，可通过该GUI以多种方式查看结果英特尔VTune(https://software.intel.com/en-us/vtune)-如果你有英特尔编译器，这很好τ(http://www.cs.uoregon.edu/research/tau/home.php)
我使用过HPCToolkit和VTune，它们在寻找帐篷中的长极点方面非常有效，并且不需要重新编译代码（除了必须在CMake中使用-g-O或RelWithDebInfo类型的内置来获得有意义的输出）。我听说TAU的能力类似。
我假设你在使用GCC。标准的解决方案是使用gprof进行分析。
在分析之前，请确保将-pg添加到编译中：
cc -o myprog myprog.c utils.c -g -pg
我还没有尝试过，但我听到了关于谷歌perftools的好消息。这绝对值得一试。
这里有相关问题。
如果gprof不适合您，还有一些流行语：Valgrind、Intel VTune、Sun DTrace。
事实上，没有多少人提到google/基准测试，这有点让人惊讶，虽然固定代码的特定区域有点麻烦，特别是如果代码库有点大的话，但是我发现这在与callgrind结合使用时非常有用
IMHO识别导致瓶颈的工件是这里的关键。不过，我会先尝试回答以下问题，然后根据这些问题选择工具
我的算法正确吗？有锁被证明是瓶颈吗？是否有一段特定的代码被证明是罪魁祸首？IO如何处理和优化？
valgrind与callgrind和kcachegrind的结合应该能对以上几点提供一个不错的估计，一旦确定某段代码存在问题，我建议做一个微基准测试——谷歌基准测试是一个很好的开始。
在工作中，我们有一个非常好的工具，它可以帮助我们监控我们想要的日程安排。这已多次有用。
它是用C++编写的，必须根据您的需要进行定制。不幸的是，我不能共享代码，只有概念。您使用一个包含时间戳和事件ID的“大”易失性缓冲区，可以在死后或停止日志系统后转储（例如，将其转储到文件中）。
您检索包含所有数据的所谓大缓冲区，一个小接口解析它并显示带有名称（up/down+value）的事件，就像示波器使用颜色（在.hpp文件中配置）所做的那样。
您可以自定义生成的事件数量，以仅关注您所需的内容。它帮助我们解决了调度问题，同时根据每秒记录的事件数量消耗了所需的CPU数量。
您需要3个文件：
toolname.hpp // interface
toolname.cpp // code
tool_events_id.hpp // Events ID
其概念是在tool_events_id.hpp中定义如下事件：
// EVENT_NAME ID BEGIN_END BG_COLOR NAME
#define SOCK_PDU_RECV_D 0x0301 //@D00301 BGEEAAAA # TX_PDU_Recv
#define SOCK_PDU_RECV_F 0x0302 //@F00301 BGEEAAAA # TX_PDU_Recv
您还可以在toolname.hpp中定义一些函数：
#define LOG_LEVEL_ERROR 0
#define LOG_LEVEL_WARN 1
// ...
void init(void);
void probe(id,payload);
// etc
代码中可以使用的任何位置：
toolname<LOG_LEVEL>::log(EVENT_NAME,VALUE);
probe函数使用几条装配线尽快检索时钟时间戳，然后在缓冲区中设置一个条目。我们还有一个原子增量来安全地找到存储日志事件的索引。当然，缓冲区是圆形的。
希望这个想法不会因为缺少示例代码而混淆。
