程序分析工具gprof
程序分析工具gprof介绍
程序分析是以某种语言书写的程序为对象，对其内部的运作流程进行分析。程序分析的目的主要有三点：一是通过程序内部各个模块之间的调用关系，整体上把握程序的运行流程，从而更好地理解程序，从中汲取有价值的内容。二是以系统优化为目的，通过对程序中关键函数的跟踪或者运行时信息的统计，找到系统性能的瓶颈，从而采取进一步行动对程序进行优化。最后一点，程序分析也有可能用于系统测试和程序调试中。当系统跟踪起来比较复杂，而某个BUG又比较难找时，可以通过一些特殊的数据构造一个测试用例，然后将分析到的函数调用关系和运行时实际的函数调用关系进行对比，从而找出错误代码的位置。
程序分析工具不同于调试器，它只产生程序运行时某些函数的调用次数、执行时间等等宏观信息，而不是每条语句执行时的详细信息。Gprof是Linux下一个强有力的程序分析工具。对于C、Pascal或者Fortran77语言的程序，它能够以“日志”的形式记录程序运行时的统计信息：程序运行中各个函数消耗的时间和函数调用关系，以及每个函数被调用的次数等等。从而可以帮助程序员找出众多函数中耗时最多的函数，也可以帮助程序员分析程序的运行流程。相信这些功能对于分析开源代码的程序员来说，有着相当大的诱惑力。
用gprof分析程序
用gprof对程序进行分析主要分以下三个步骤：
l 用编译器对程序进行编译，加上-pg参数。
l 运行编译后的程序。
l 用gprof命令查看程序的运行时信息。
先以一个简单的例子演示一下吧。随便找一个能够运行的程序的源代码，比如下面的文件test.c：
2 int IsEven(int x)
3
4 {
5
6 return 0 == x & 1;
7
8 }
9
10 int main(int argc, char *argv[]
11
12 {
13
14 int i = 0;
15
16 while(++i < 1000) IsEven(i);
17
18 }
首先，用以下命令进行编译：
[root@localhost]#gcc –o test –pg test.c
然后，运行可执行文件test.
[root@localhost]#./test
运行后，在当前目录下将生成一个文件gmon.out，这就是gprof生成的文件，保存有程序运行期间函数调用等信息。
最后，用gprof命令查看gmon.out保存的信息：
[root@localhost]#gprof test gmon.out –b
这样就有一大堆信息输出到屏幕上，有函数执行单间，函数调用关系图等等，如下：
Flat profile:
Each sample counts as 0.01 seconds.
no time accumulated
% cumulative self self total
time seconds seconds calls Ts/call Ts/call name
0.00 0.00 0.00 1000 0.00 0.00 IsEven(int)
Call graph
granularity: each sample hit covers 2 byte(s) no time propagated
index % time self children called name
0.00 0.00 1000/1000 main [7]
[8] 0.0 0.00 0.00 1000 IsEven(int) [8]
-----------------------------------------------
Index by function name
[8] IsEven(int)
以上介绍了gprof最简单的使用方法，下面针对其使用过程中的三个步骤详细说明。
编译和链接
上面的例子中，程序比较简单，只有一个文件。如果源代码有多个文件，或者代码结构比较复杂，编译过程中先生成若干个目标文件，然后又由链接器将这些目标文件链接到一起，这时该怎么使用gprof呢？
对于由多个源文件组成的程序，编译时需要在生成每个.o文件的时候加上-pg参数，同时在链接的时候也要加上-pg参数。对于链接器不是GCC的情况，如ld，又有特殊的要求。
同时，-pg参数只能记录源代码中各个函数的调用关系，而不能记录库函数的调用情况。要想记录每个库函数的调用情况，链接的时候必须指定库函数的动态（或者静态）链接库libc_p.a，即加上-lc_p，而不是-lc。
还要说明的是，如果有一部分代码在编译时指定了-pg参数，而另一部分代码没有指定，则生成的gmon.out文件中将缺少一部分函数，也没有那些函数的调用关系。但是并不影响gprof对其它函数进行记录。
运行
编译好的程序运行时和运行一般的程序没有什么不同，只是比正常的程序多生成了一个文件gmon.out。注意，这个文件名是固定的，没法通过参数的设置进行改变。如果程序目录中已经有一个gmon.out，则它会被新的gmon.out覆盖掉。
关于生成的gmon.out文件所在的目录，也有以下约定：程序退出时所运行的文件所在目录就是生成的gmon.out文件所在的目录。如果一个程序执行过程中调用了另一个程序，并在另一个程序的运行中终止，则gmon.out会在另一个程序所在的目录中生成。
还有一点要注意的就是当程序非正常终止时不会生成gmon.out文件，也因此就没法查看程序运行时的信息。只有当程序从main函数中正常退出，或者通过系统调用exit()函数而退出时，才会生成gmon.out文件。而通过底层调用如_exit()等退出时不会生成gmon.out。
查看
查看程序运行信息的命令是gprof，它以gmon.out文件作为输入，也就是将gmon.out文件翻译成可读的形式展现给用户。其命令格式如下：
gprof [可执行文件] [gmon.out文件] [其它参数]
方括号中的内容可以省略。如果省略了“可执行文件”，gprof会在当前目录下搜索a.out文件作为可执行文件，而如果省略了gmon.out文件，gprof也会在当前目录下寻找gmon.out。其它参数可以控制gprof输出内容的格式等信息。最常用的参数如下：
l -b 不再输出统计图表中每个字段的详细描述。
l -p 只输出函数的调用图（Call graph的那部分信息）。
l -q 只输出函数的时间消耗列表。
l -e Name 不再输出函数Name 及其子函数的调用图（除非它们有未被限制的其它父函数）。可以给定多个 -e 标志。一个 -e 标志只能指定一个函数。
l -E Name 不再输出函数Name 及其子函数的调用图，此标志类似于 -e 标志，但它在总时间和百分比时间的计算中排除了由函数Name 及其子函数所用的时间。
l -f Name 输出函数Name 及其子函数的调用图。可以指定多个 -f 标志。一个 -f 标志只能指定一个函数。
l -F Name 输出函数Name 及其子函数的调用图，它类似于 -f 标志，但它在总时间和百分比时间计算中仅使用所打印的例程的时间。可以指定多个 -F 标志。一个 -F 标志只能指定一个函数。-F 标志覆盖 -E 标志。
l -z 显示使用次数为零的例程（按照调用计数和累积时间计算）。
不过,gprof不能显示对象之间的继承关系,这也是它的弱点.
转自：
http://www.cnblogs.com/huangpeng/archive/2009/02/17/1392456.html
使用 GNU profiler 来提高代码运行速度
寻找应用程序中占用时间最长的部分
简介
各种软件对于性能的需求可能会有很大的区别，但是很多应用程序都有非常严格的性能需求，这一点并不奇怪。电影播放器就是一个很好的例子：如果一个电影播放器只能以所需要速度的 75% 来播放电影，那么它几乎就没什么用处了。
其他应用程序（例如视频编码）如果是耗时非常长的操作，最好以 “批处理” 任务的方式运行，此时启动一个作业，让其一直运行，然后我们就可以去干别的事情了。尽管这些类型的应用程序没有这种硬性性能指标的限制，但是提高速度仍然会带来很多好处，例如可以在给定的时间内可以对更多电影进行编码，在同样的时间内可以以更高的品质进行编码。
通常，除了最简单的应用程序之外，对于其他应用程序来说，性能越好，这个应用程序的用处就越大，也就会越流行。由于这个原因，性能考虑是（也应该是）很多应用程序开发人员脑袋中的第一根弦。
不幸的是，很多尝试让应用程序速度更快的努力都白费了，因为开发人员通常都是对自己的软件进行一些小型的优化，而没有去研究程序在更大的范围内是如何操作的。例如，我们可能会花费大量的时间来让某个特定函数的运行速度达到原来的两倍，这一点非常不错，但是如果这个函数很少被调用（例如打开文件），那么将这个函数的执行时间从 200ms 减少到 100ms，对于整个软件的总体执行时间来说并不会有太大的影响。
有效地利用您的时间的方法是，尽量优化软件中被频繁调用的部分。例如，假设应用程序花了 50% 的时间在字符串处理函数上，如果可以对这些函数进行优化，提高 10% 的效率，那么应用程序的总体执行时间就会改进 5%。
因此，如果希望能够有效地对程序进行优化，那么精确地了解时间在应用程序中是如何花费的，以及真实的输入数据，这一点非常重要。这种行为就称为代码剖析（code profiling）。本文将简要介绍 GNU 编译器工具包所提供的一种剖析工具，它的名字让人可以产生无限遐想，叫 GNU profiler（gprof）。本文主要面向那些开放源码软件开发工具的新手。
gprof 来救援了
在开始介绍如何使用 gprof 之前，需要首先了解一下在整个开发周期中，剖析应该在何处进行。通常来说，编写代码应该有 3 个目标，按照重要性的次序分别如下所示：
- 保证软件可以正确地工作。这通常是开发过程的重点。通常，如果一个软件根本连我们期望它做的事情都实现不了，那么即使它运行速度非常快，也根本没有任何意义！显然，正确性在某些情况下可能并不是至关重要的；例如，如果一个电影播放器可以正确地播放 99% 的电影文件，但是偶然会有些显示问题，那它依然可以使用。但是通常来说，正确性要远远比速度更加重要。
- 保证软件是可维护的。这实际上是第一个目标的一个子项。通常，如果软件编写得可维护性不好，那么即使它最开始时可以很好地工作，很快您（或其他人）在修正 bug 或添加新特性时可能也会破坏程序的正确性。
- 让软件可以快速运行。这就是剖析的用武之地。当软件可以正确运行之后，我们就可以开始剖析的过程来帮助它更快地运行了。
假设我们现在已经有了一个可以工作的应用程序，接下来让我们来看一下如何使用 gprof 来精确测量应用程序执行过程中时间都花费到什么地方去了，这样做的目的是了解一下在什么地方进行优化效果最佳。
gprof 可以对 C、C++、Pascal 和 Fortran 77 应用程序进行剖析。本文中的例子使用的是 C。
清单 1. 耗时的应用程序示例
#include <stdio.h>
int a(void) {
int i=0,g=0;
while(i++<100000)
{
g+=i;
}
return g;
}
int b(void) {
int i=0,g=0;
while(i++<400000)
{
g+=i;
}
return g;
}
int main(int argc, char** argv)
{
int iterations;
if(argc != 2)
{
printf("Usage %s <No of Iterations>\n", argv[0]);
exit(-1);
}
else
iterations = atoi(argv[1]);
printf("No of iterations = %d\n", iterations);
while(iterations--)
{
a();
b();
}
}
|
正如我们从代码中可以看到的，这个非常简单的应用程序包括两个函数：a 和 b，它们都处于一个繁忙的循环中消耗 CPU 周期。main函数中采用了一个循环来反复调用这两个函数。第二个函数 b 循环的次数是 a 函数的 4 倍，因此我们期望在对代码分析完之后，可以看出大概有 20% 的时间花在了 a 函数中，而 80% 的时间花在了 b 函数中。下面就开始剖析代码，并看一下我们的这些期望是否正确。
启用剖析非常简单，只需要在 gcc 编译标志中加上 -pg 即可。编译方法如下：
gcc example1.c -pg -o example1 -O2 -lc
在编译好这个应用程序之后，可以按照普通方式运行这个程序：
./example1 50000
当这个程序运行完之后，应该会看到在当前目录中新创建了一个文件 gmon.out。
使用输出结果
首先看一下 “flat profile”，我们可以使用 gprof 命令获得它，这需要为其传递可执行文件和 gmon.out 文件作为参数，如下所示：
gprof example1 gmon.out -p
这会输出以下内容：
清单 2. flat profile 的结果
Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 80.24 63.85 63.85 50000 1.28 1.28 b 20.26 79.97 16.12 50000 0.32 0.32 a |
从这个输出结果中可以看到，正如我们期望的一样，b 函数所花费的时间大概是 a 函数所花费的时间的 4 倍。真正的数字并不是十分有用；由于取整舍入错误，这些数字可能并不是非常精确。
聪明的读者可能会注意到，很多函数调用（例如 printf）在这个输出中都没有出现。这是因为这些函数都是在 C 运行时库（libc.so）中的，（在本例中）它们都没有使用 -pg 进行编译，因此就没有对这个库中的函数收集剖析信息。稍后我们会回到这个问题上来。
接下来我们希望了解的是 “call graph”，这可以通过下面的方式获得：
gprof example1 gmon.out -q
这会输出下面的结果。
清单 3. Call graph
Call graph (explanation follows)
granularity: each sample hit covers 2 byte(s) for 0.01% of 79.97 seconds
index % time self children called name
<spontaneous>
[1] 100.0 0.00 79.97 main [1]
63.85 0.00 50000/50000 b [2]
16.12 0.00 50000/50000 a [3]
-----------------------------------------------
63.85 0.00 50000/50000 main [1]
[2] 79.8 63.85 0.00 50000 b [2]
-----------------------------------------------
16.12 0.00 50000/50000 main [1]
[3] 20.2 16.12 0.00 50000 a [3]
-----------------------------------------------
|
最后，我们可能会希望获得一个 “带注解的源代码” 清单，它会将源代码输出到应用程序中，并加上每个函数被调用了多少次的注释。
要使用这种功能，请使用启用调试功能的标志来编译源代码，这样源代码就会被加入可执行程序中：
gcc example1.c -g -pg -o example1 -O2 -lc
像以前一样重新运行这个应用程序：
./example1 50000
gprof 命令现在应该是：
gprof example1 gmon.out -A
这会输出下面的结果：
清单 4. 带注释的源代码
*** File /home/martynh/profarticle/example1.c:
#include <stdio.h>
50000 -> int a(void) {
int i=0,g=0;
while(i++<100000)
{
g+=i;
}
return g;
}
50000 -> int b(void) {
int i=0,g=0;
while(i++<400000)
{
g+=i;
}
return g;
}
int main(int argc, char** argv)
##### -> {
int iterations;
if(argc != 2)
{
printf("Usage %s <No of Iterations>\n", argv[0]);
exit(-1);
}
else
iterations = atoi(argv[1]);
printf("No of iterations = %d\n", iterations);
while(iterations--)
{
a();
b();
}
}
Top 10 Lines:
Line Count
3 50000
11 50000
Execution Summary:
3 Executable lines in this file
3 Lines executed
100.00 Percent of the file executed
100000 Total number of line executions
33333.33 Average executions per line
|
共享库的支持
正如在前面曾经介绍的，对于代码剖析的支持是由编译器增加的，因此如果希望从共享库（包括 C 库 libc.a）中获得剖析信息，就需要使用 -pg 来编译这些库。幸运的是，很多发行版都提供了已经启用代码剖析支持而编译的 C 库版本（libc_p.a）。
在我使用的发行版 gentoo 中，需要将 “profile” 添加到 USE 标志中，并重新执行 emerge glibc。当这个过程完成之后，就会看到 /usr/lib/libc_p.a 文件已经创建好了。对于没有按照标准提供 libc_p 的发行版本来说，需要检查它是否可以单独安装，或者可能需要自己下载 glibc 的源代码并进行编译。
在获得 libc_p.a 文件之后，就可以简单地重新编译前面的例子了，方法如下：
gcc example1.c -g -pg -o example1 -O2 -lc_p
然后，可以像以前一样运行这个应用程序，并获得 flat profile 或 call graph，应该会看到很多 C 运行函数，包括 printf（这些函数在我们的测试函数中并不是太重要）。
用户时间与内核时间
现在我们已经知道如何使用 gprof 了，接下来可以简单且有效地对应用程序进行分析了，希望可以消除性能瓶颈。
不过现在您可能已经注意到了 gprof 的最大缺陷：它只能分析应用程序在运行 过程中所消耗掉的用户 时间。通常来说，应用程序在运行时既要花费一些时间来运行用户代码，也要花费一些时间来运行 “系统代码”，例如内核系统调用。
如果对清单 1 稍加修改，就可以清楚地看出这个问题：
清单 5. 为清单 1 添加系统调用分析功能
#include <stdio.h>
int a(void) {
sleep(1);
return 0;
}
int b(void) {
sleep(4);
return 0;
}
int main(int argc, char** argv)
{
int iterations;
if(argc != 2)
{
printf("Usage %s <No of Iterations>\n", argv[0]);
exit(-1);
}
else
iterations = atoi(argv[1]);
printf("No of iterations = %d\n", iterations);
while(iterations--)
{
a();
b();
}
}
|
正如您可以看到的，我们对清单 1 中的代码进行了修改，现在 a 函数和 b 函数不再只处理繁忙的循环了，而是分别调用 C 运行时函数sleep 来挂起执行 1 秒和 4 秒。
像以前一样编译这个应用程序：
gcc example2.c -g -pg -o example2 -O2 -lc_p
并让这个程序循环 30 次：
./example2 30
所生成的 flat profile 如下所示：
清单 6. flat profile 显示了系统调用的结果
Flat profile: Each sample counts as 0.01 seconds. no time accumulated % cumulative self self total time seconds seconds calls Ts/call Ts/call name 0.00 0.00 0.00 120 0.00 0.00 sigprocmask 0.00 0.00 0.00 61 0.00 0.00 __libc_sigaction 0.00 0.00 0.00 61 0.00 0.00 sigaction 0.00 0.00 0.00 60 0.00 0.00 nanosleep 0.00 0.00 0.00 60 0.00 0.00 sleep 0.00 0.00 0.00 30 0.00 0.00 a 0.00 0.00 0.00 30 0.00 0.00 b 0.00 0.00 0.00 21 0.00 0.00 _IO_file_overflow 0.00 0.00 0.00 3 0.00 0.00 _IO_new_file_xsputn 0.00 0.00 0.00 2 0.00 0.00 _IO_new_do_write 0.00 0.00 0.00 2 0.00 0.00 __find_specmb 0.00 0.00 0.00 2 0.00 0.00 __guard_setup 0.00 0.00 0.00 1 0.00 0.00 _IO_default_xsputn 0.00 0.00 0.00 1 0.00 0.00 _IO_doallocbuf 0.00 0.00 0.00 1 0.00 0.00 _IO_file_doallocate 0.00 0.00 0.00 1 0.00 0.00 _IO_file_stat 0.00 0.00 0.00 1 0.00 0.00 _IO_file_write 0.00 0.00 0.00 1 0.00 0.00 _IO_setb 0.00 0.00 0.00 1 0.00 0.00 ____strtol_l_internal 0.00 0.00 0.00 1 0.00 0.00 ___fxstat64 0.00 0.00 0.00 1 0.00 0.00 __cxa_atexit 0.00 0.00 0.00 1 0.00 0.00 __errno_location 0.00 0.00 0.00 1 0.00 0.00 __new_exitfn 0.00 0.00 0.00 1 0.00 0.00 __strtol_internal 0.00 0.00 0.00 1 0.00 0.00 _itoa_word 0.00 0.00 0.00 1 0.00 0.00 _mcleanup 0.00 0.00 0.00 1 0.00 0.00 atexit 0.00 0.00 0.00 1 0.00 0.00 atoi 0.00 0.00 0.00 1 0.00 0.00 exit 0.00 0.00 0.00 1 0.00 0.00 flockfile 0.00 0.00 0.00 1 0.00 0.00 funlockfile 0.00 0.00 0.00 1 0.00 0.00 main 0.00 0.00 0.00 1 0.00 0.00 mmap 0.00 0.00 0.00 1 0.00 0.00 moncontrol 0.00 0.00 0.00 1 0.00 0.00 new_do_write 0.00 0.00 0.00 1 0.00 0.00 printf 0.00 0.00 0.00 1 0.00 0.00 setitimer 0.00 0.00 0.00 1 0.00 0.00 vfprintf 0.00 0.00 0.00 1 0.00 0.00 write |
如果对这个输出结果进行分析，我们就会看到，尽管 profiler 已经记录了每个函数被调用的确切次数，但是为这些函数记录的时间（实际上是所有函数）都是 0.00。这是因为 sleep 函数实际上是执行了一次对内核空间的调用，从而将应用程序的执行挂起了，然后有效地暂停执行，并等待内核再次将其唤醒。由于花在用户空间执行的时间与花在内核中睡眠的时间相比非常小，因此就被取整成零了。其原因是 gprof 仅仅是通过以固定的周期对程序运行时间 进行采样测量来工作的。因此，当程序不运行时，就不会对程序进行采样测量。
这实际上是一把双刃剑。从一个方面来说，这使得有些程序非常难以进行优化，例如花费大部分时间在内核空间的程序，或者由于外部因素（例如操作系统的 I/O 子系统过载）而运行得非常慢的程序。从另一个方面来说，这意味着剖析不会受到系统中其他事件的影响（例如另外一个用户使用了大量的 CPU 时间）。
通常，有一个很好的基准测试可以用来查看 gprof 对于帮助对应用程序进行优化是多么有用，方法是在 time 命令下面执行它。这个命令会显示一个应用程序运行完成需要多少时间，并可以测量它在用户空间和内核空间各花费了多少时间。
如果查看一下清单 2 中的例子：
time ./example2 30
输出结果应该如下所示：
清单 7. time 命令的输出结果
No of iterations = 30 real 2m30.295s user 0m0.000s sys 0m0.004s |
我们可以看出几乎没有多少时间被花费在执行用户空间的代码上，因此 gprof 在此处不会非常有用。
结束语
尽管 gprof 存在上面的限制，但是它对于优化代码来说依然是个非常有用的工具，如果您的代码大部分是用户空间 CPU 密集型的，它的用处就更加明显。首先使用 time 来运行程序从而判断 gprof 是否能产生有用信息是个好主意。
如果 gprof 不适合您的剖析需要，那么还有其他一些工具可以克服 gprof 部分缺陷，包括 OProfile 和 Sysprof （请参看 参考资料 中有关这些工具信息的链接）。
从另一个方面来说，假设我们已经安装了 gcc，gprof 相对于其他工具来说，一个主要的优点是很可能早已在 Linux 机器上安装了需要使用的工具。
参考资料
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- 有关使用 gprof 的更多信息，请参阅 GNU profiler 手册。
- 在 “使用 OProfile for Linux on POWER 识别性能瓶颈”（developerWorks，2005 年 5 月）和 “用 OProfile 彻底了解性能”（developerWorks，2003 年 10 月）中学习更多有关 OProfile 的知识。
- 请访问 OProfile 主页。
- 请阅读更多有关 System-wide Linux profiler (Sysprof) 的内容。
- 在 developerWorks Linux 专区 中可以找到为 Linux 开发人员准备的更多参考资料。
- 紧密跟踪 developerWorks 技术活动和 Webcasts。
获得产品和技术
- 索取免费的 SEK for Linux，这有两张 DVD，包括最新的 IBM for Linux 的试用版软件，包括 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere®。
- 在您的下一个 Linux 开发项目中采用 IBM 试用版软件，这可以从 developerWorks 上直接下载。
讨论
- 通过参与 developerWorks blogs 来加入 developerWorks 社区。
关于作者
Martyn Honeyford 1996 年毕业于诺丁汉大学，获计算机科学学士学位。从那时起，他就成为位于英格兰 Hursley 的 IBM 英国实验室的一名软件工程师。他目前的职务是 WebSphere MQ Everyplace 开发团队中的一名开发人员。在不工作的时候，他经常弹电吉他（弹得很差）或者疯狂地玩电子游戏。可以通过 [email protected] 与 Martyn 联系。