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

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

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

我会使用Valgrind和Callgrind作为我的仿形工具套件的基础。重要的是，Valgrind基本上是一台虚拟机：

（维基百科）Valgrind本质上是虚拟的机器使用准时制（JIT）编译技术，包括动态重新编译。没有来自的内容原始程序始终运行直接在主机处理器上。相反，Valgrind首先翻译将程序转换为临时的、更简单的形式称为中间表示（IR）是处理器中性的，转换后，工具（见下文）可以自由使用无论它想要什么样的转变在Valgrind翻译之前IR返回到机器代码中主机处理器运行它。

Callgrind是一个基于此的剖析器。主要的好处是，您不必运行应用程序数小时就能获得可靠的结果。因为Callgrind是一个非探测型剖面仪，所以即使一秒钟的运行也足以获得可靠的结果。

另一个基于Valgrind的工具是Massif。我使用它来分析堆内存使用情况。它工作得很好。它的作用是为您提供内存使用情况的快照--详细信息What hold What percentage of memory，and WHO has put it there。这些信息在应用程序运行的不同时间点可用。

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

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

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

由于没有人提到Arm MAP，我想补充一下，因为我个人已经成功地使用了MAP来描述C++科学程序。

Arm MAP是并行、多线程或单线程C、C++、Fortran和F90代码的分析器。它提供了深入的分析和对源代码线的瓶颈定位。与大多数评测器不同，它被设计为能够评测pthreads、OpenMP或MPI的并行和线程代码。

MAP是商业软件。

您可以使用loguru这样的日志框架，因为它包括时间戳和总运行时间，可以很好地用于分析：

我假设你在使用GCC。标准的解决方案是使用gprof进行分析。

在分析之前，请确保将-pg添加到编译中：

cc -o myprog myprog.c utils.c -g -pg

我还没有尝试过，但我听到了关于谷歌perftools的好消息。这绝对值得一试。

这里有相关问题。

如果gprof不适合您，还有一些流行语：Valgrind、Intel VTune、Sun DTrace。