<<程序设计实践>>：
“使用轮廓程序。除了可靠的计时方法外，在性能分析中最重要的工具就是一种能产生轮廓文件的系统。轮廓文件是对程序在哪些地方消耗了时间的一种度量。在 有些轮廓文件中列出了执行中调用的各个函数、各函数被调用的次数以及它们消耗的时间在整个执行中的百分比。另一些轮廓文件计算每个语句执行的次数。执行非 常频繁的语句通常对总运行时间的贡献比较大，根本没执行的语句所指明的可能是些无用代码，或者是没有合理测试到的代码。轮廓文件是一种发现程序中执行热点的有效手段，所谓热点就是那些消耗了大部分计算时间的函数或者代码段。当然，对轮廓文件的解释也应该慎重。由于编译程序本身的复杂性、缓冲存储器和主存的复杂影响，还有做程序的轮廓文件对其本身执行所造成的影响等，轮廓文件的统计信息只能看作是近似的.轮廓文件常常可以通过编译系统的一个标志或选择项打开，然后运行程序，最后用一个分析工具显示结果。在U n i x上，这个标志一般是- p，对应的工具是p r o f“
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
来源:
blog.csdn.net/lengxingfei/archive/2006/01/20/584889.aspx
在优化程序的时候，要记住：在值得优化的地方优化！没有必要花上几个小时来优化一段实际上只运行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
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
另外，还可以参考：
使用 GNU profiler 来提高代码运行速度
寻找应用程序中占用时间最长的部分