摘要:

在优化程式的时候，要记住：在值得优化的地方优化！没有必要花上几个小时来优化一段实际上只运行0.04秒的程式。

GProf 使用了一种异常简单但是很有效的方法来优化C/C++ 程式，而且能很容易的识别出值得优化的代码。一个简单的案例分析将会显示，GProf怎样通过识别并优化两个关键的数据结构，将实际应用中的程式从3分钟的运行时优化到5秒的。

这个程式最早能够追溯到1982年关于编译器构建的特别讨论大会（the SIGPLAN Symposium on Compiler Construction）。现在这个程式成了各种UNIX 平台上的一个标准工具。 

Profiling in a nutshell

程式概要分析的概念很简单：通过记录各个函数的调用和结束时间，我们能够计算出程式的最大运行时的程式段。这种方法听起来似乎要花费很多气力??幸运的是，我们其实离真理并不远！我们只需要在用 gcc 编译时加上一个额外的参数(’-pg’)，运行这个（编译好的）程式（来搜集程式概要分析的有关数据），然后运行’gprof’以更方便的分析这些结果。  

案例分析: Pathalizer

我使用了一个现实中使用的程式来作为例子，是 pathalizer的一部分: 即event2dot，一个将路径“事件”描述文档转化为图像化“dot”文档的工具（executable which translates a pathalizer ’events’ file to a graphviz ’dot’ file）。

简单的说，他从一个文档里面读取各种事件，然后将他们分别保存为图像(以页为节点，且将页和页之间的转变作为边），然后将这些图像整合为一张大的图像，并保存为图像化的’dot’格式文档。  

给程式计时

先让我们给我们未经优化的程式计一下时，看看他们的运行要多少时间。在我的电脑上使用event2dot并用源码里的例子作为输入（大概55000的数据），大致要三分多钟：

real    3m36.316s
user    0m55.590s
sys     0m1.070s

程式分析

要使用gprof 作概要分析，在编译的时候要加上’-pg’ 选项，我们就是如下重新编译源码如下：

g++ -pg dotgen.cpp readfile.cpp main.cpp graph.cpp config.cpp -o event2dot

现在我们能够再次运行event2dot，并使用我们前面使用的测试数据。这次我们运行的时候，event2dot运行的分析数据会被搜集并保存在’gmon.out’文档中，我们能够通过运行’gprof event2dot | less’来查看结果。

gprof 会显示出如下的函数比较重要：

 % cumulative  self              self     total
 time seconds  seconds  calls s/call s/call name
43.32   46.03  46.03 339952989  0.00  0.00 CompareNodes(Node *,Node *)
25.06   72.66  26.63    55000   0.00  0.00 getNode(char *,NodeListNode *&)
16.80   90.51  17.85 339433374  0.00  0.00 CompareEdges(Edge *,AnnotatedEdge *)
12.70  104.01  13.50    51987   0.00  0.00 addAnnotatedEdge(AnnotatedGraph *,Edge *)
 1.98  106.11   2.10    51987   0.00  0.00 addEdge(Graph *,Node *,Node *)
 0.07  106.18   0.07        1   0.07  0.07 FindTreshold(AnnotatedEdge *,int)
 0.06  106.24   0.06        1   0.06 28.79 getGraphFromFile(char *,NodeListNode *&,Config *)
 0.02  106.26   0.02        1   0.02 77.40 summarize(GraphListNode *,Config *)
 0.00  106.26   0.00    55000   0.00  0.00 FixName(char *)

能够看出，第一个函数比较重要: 程式里面绝大部分的运行时都被他给占据了。  

优化

上面结果能够看出，这个程式大部分的时间都花在了CompareNodes函数上，用 grep 查看一下则发现CompareNodes 只是被CompareEdges调用了一次而已, 而CompareEdges则只被addAnnotatedEdge调用??他们都出现在了上面的清单中。这儿就是我们应该做点优化的地方了吧！

我们注意到addAnnotatedEdge遍历了一个链表。虽然链表是易于实现，但是却实在不是最好的数据类型。我们决定将链表 g->edges 用二叉树来代替: 这将会使得查找更快。  

结果

现在我们看一下优化后的运行结果:

real    2m19.314s
user    0m36.370s
sys     0m0.940s

第二遍

再次运行 gprof 来分析:

%   cumulative self           self    total
 time   seconds seconds calls  s/call  s/call name
87.01     25.25  25.25  55000    0.00    0.00 getNode(char *,NodeListNode *&)
10.65     28.34   3.09  51987    0.00    0.00 addEdge(Graph *,Node *,Node *)

看起来以前占用大量运行时的函数现在已不再是占用运行时的大头了！我们试一下再优化一下呢：用节点哈希表来取代节点树。

这次简直是个巨大的进步:

real    0m3.269s
user    0m0.830s
sys     0m0.090s

其他 C/C++ 程式分析器

更有其他很多分析器能够使用gprof 的数据, 例如KProf (截屏) 和 cgprof。虽然图像界面的看起来更舒服，但我个人认为命令行的gprof 使用更方便。
 

对其他语言的程式进行分析

我们这里介绍了用gprof 来对C/C++ 的程式进行分析，对其他语言其实相同能够做到: 对 Perl,我们能够用Devel::DProf 模块。您的程式应该以perl -d:DProf mycode.pl来开始，并使用dprofpp来查看并分析结果。假如您能够用gcj 来编译您的Java 程式，您也能够使用gprof，然而现在还只支持单线程的Java 代码。  

结论

就像我们已看到的，我们能够使用程式概要分析快速的找到一个程式里面值得优化的地方。在值得优化的地方优化，我们能够将一个程式的运行时从 3分36秒 减少到少于 5秒，就像从上面的例子看到的相同。  

References

• Pathalizer: http://pathalizer.sf.net
  
  
• KProf: http://kprof.sf.net
  
  
• cgprof: http://mvertes.free.fr
  
  
• Devel::DProf http://www.perldoc.com/perl5.8.0/lib/Devel/DProf.html
  
  
• gcj: http://gcc.gnu.org/java
  
  
• : pathalizer example files: download for article371