使用调试软件如何识别代码运行缓慢的地方？

如果你在运动中遇到障碍物，那么它会降低你的速度

如不需要的重新分配的循环、缓冲区溢出、搜索、内存泄漏等操作消耗更多的执行能力，这将对代码的性能产生不利影响，在分析之前，请确保将-pg添加到编译中：

g++your_prg.cpp-pg或cc my_program.cpp-g-pg（根据编译器）

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

valgrind--tool=callgrind/（二进制文件）

它将生成一个名为gmon.out或callgrind.out.x的文件。然后可以使用kcachegrind或调试器工具来读取该文件。它会给你一个图形化的分析结果，比如哪一行花费多少。

我认为是这样

如果没有一些选项，运行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”显示每个函数本身花费的时间，而不是与依赖项一起花费的时间。

我会使用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。这些信息在应用程序运行的不同时间点可用。

编译和链接代码并运行可执行文件时，请使用-pg标志。执行此程序时，分析数据收集在文件a.out中。有两种不同类型的分析

1-平面轮廓：通过运行命令gprog--flat profile a.out，可以获得以下数据-该功能所花费的总时间的百分比，-在包括和排除对子函数的调用的函数中花费了多少秒，-呼叫的数量，-每次通话的平均时间。

2-图形分析使用命令gprof--graph a.out获取每个函数的以下数据，其中包括-在每个部分中，一个函数都标有索引编号。-在函数上方，有一个调用该函数的函数列表。-在函数下面，有一个函数调用的函数列表。

要获取更多信息，请查看https://sourceware.org/binutils/docs-2.32/gprof/

使用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工具）

这是对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，如果这对任何人都有帮助的话。