c语言关掉编译优化,C/C++写的程序特别大怎么办好呢用GProf可以优化完全解决这个问题...

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

第二遍

%

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:

Prof 模块。你的程序应该以perl -d

Prof

mycode.pl来开始，并使用dprofpp来查看并分析结果。如果你可以用gcj 来编译你的Java

程序，你也可以使用gprof，然而目前还只支持单线程的Java 代码。

就像我们已经看到的，我们可以使用程序概要分析快速的找到一个程序里面值得优化的地方。在值得优化的地方优化，我们可以将一个程序的运行时从

3分36秒 减少到少于 5秒，就像从上面的例子看到的一样。