在工作中，我们有一个非常好的工具，它可以帮助我们监控我们想要的日程安排。这已多次有用。

它是用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函数使用几条装配线尽快检索时钟时间戳，然后在缓冲区中设置一个条目。我们还有一个原子增量来安全地找到存储日志事件的索引。当然，缓冲区是圆形的。

希望这个想法不会因为缺少示例代码而混淆。

使用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--tool=callgrind的答案并不完全。我们通常不希望在Valgrind下描述10分钟的缓慢启动时间，而希望在执行某些任务时描述我们的程序。

这就是我的建议。首先运行程序：

valgrind --tool=callgrind --dump-instr=yes -v --instr-atstart=no ./binary > tmp

现在，当它工作并且我们想要开始评测时，我们应该在另一个窗口中运行：

callgrind_control -i on

这将打开分析。若要关闭并停止整个任务，我们可以使用：

callgrind_control -k

现在，我们在当前目录中有一些名为callgrind.out.*的文件。要查看分析结果，请使用：

kcachegrind callgrind.out.*

我建议在下一个窗口中单击“Self”列标题，否则它会显示“main（）”是最耗时的任务。“Self”显示每个函数本身花费的时间，而不是与依赖项一起花费的时间。

还值得一提的是

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的能力类似。

这是对Nazgob Gprof回答的回应。

过去几天我一直在使用Gprof，已经发现了三个重要的限制，其中一个是我在其他地方还没有看到过的：

它不能在多线程代码上正常工作，除非您使用变通方法调用图被函数指针弄糊涂了。示例：我有一个名为multithread（）的函数，它使我能够在指定的数组上对指定的函数进行多线程处理（两者都作为参数传递）。然而，Gprof将所有对多线程（）的调用视为等效的，以计算在孩子身上花费的时间。由于我传递给多线程（）的一些函数花费的时间比其他函数长得多，所以我的调用图基本上是无用的。（对于那些想知道线程是否是这里的问题的人来说：不，多线程（）可以选择，在这种情况下，只在调用线程上按顺序运行所有内容）。这里说“……调用数数字是通过计数而不是采样得出的。它们是完全准确的……”。然而，我发现我的调用图给了我5345859132+784984078作为对我调用最多的函数的调用统计数据，其中第一个数字应该是直接调用，第二个递归调用（都来自它本身）。因为这意味着我有一个bug，所以我在代码中加入了长（64位）计数器，并再次运行相同的程序。我的计数：5345859132个直接调用和78094395406个自递归调用。这里有很多数字，所以我要指出，我测量的递归调用是780亿，而Gprof是7.84亿：相差100倍。两次运行都是单线程和未优化的代码，一次是编译的-g，另一次是-pg。

这是在64位Debian Lenny下运行的GNUGprof（Debian的GNUBinutils）2.18.0.20080103，如果这对任何人都有帮助的话。

较新的内核（例如最新的Ubuntu内核）附带了新的“perf”工具（apt-get-install-linux-tools）AKA perf_events。

这些都配有经典的采样分析器（手册页）以及很棒的时间图表！

重要的是，这些工具可以是系统评测，而不仅仅是进程评测-它们可以显示线程、进程和内核之间的交互，并让您了解进程之间的调度和I/O依赖关系。