使用GProf来优化你的C/C++程序 |
|
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秒，就像从上面的例子看到的一样 。 |
