C/C++写的程序特别大怎么办好呢用GProf可以优化完全解决这个问题

群发软件

	C/C++写的程序特别大怎么办好呢用GProf可以优化完全解决这个问题 Gprof 是GNU gnu binutils工具之一，默认情况下linux系统当中都带有这个工具。 1. 可以显示“flat profile”，包括每个函数的调用次数，每个函数消耗的处理器时间， 2. 可以显示“Call graph”，包括函数的调用关系，每个函数调用花费了多少时间。 3. 可以显示“注释的源代码”－－是程序源代码的一个复本，标记有程序中每行代码的执行次数。 3 原理 通过在编译和链接程序的时候（使用 -pg 编译和链接选项），gcc 在你应用程序的每个函数中都加入了一个名为mcount ( or  “_mcount”  , or  “__mcount” , 依赖于编译器或操作系统)的函数，也就是说你的应用程序里的每一个函数都会调用mcount, 而mcount 会在内存中保存一张函数调用图，并通过函数调用堆栈的形式查找子函数和父函数的地址。这张调用图也保存了所有与函数相关的调用时间，调用次数等等的所有信息。 4 使用流程 1. 在编译和链接时 加上-pg选项。一般我们可以加在 makefile 中。 2. 执行编译的二进制程序。执行参数和方式同以前。 3. 在程序运行目录下 生成 gmon.out 文件。如果原来有gmon.out 文件，将会被重写。 4. 结束进程。这时 gmon.out 会再次被刷新。 5. 用 gprof 工具分析 gmon.out 文件。 5 参数说明 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 –b 二进制程序 gmon.out >report.txt 6 报告说明 Gprof 产生的信息解释：   %time Cumulative seconds Self Seconds Calls Self TS/call Total TS/call name 该函数消耗时间占程序所有时间百分比 程序的累积执行时间 （只是包括gprof能够监控到的函数） 该函数本身执行时间 （所有被调用次数的合共时间） 函数被调用次数 函数平均执行时间 （不包括被调用时间） （函数的单次执行时间） 函数平均执行时间 （包括被调用时间） （函数的单次执行时间） 函数名 Call Graph 的字段含义： Index %time Self Children Called Name 索引值 函数消耗时间占所有时间百分比 函数本身执行时间 执行子函数所用时间 被调用次数 函数名 注意： 程序的累积执行时间只是包括gprof能够监控到的函数。工作在内核态的函数和没有加-pg编译的第三方库函数是无法被gprof能够监控到的，（如sleep（）等） Gprof 的具体参数可以 通过 man gprof 查询。 7 共享库的支持 对于代码剖析的支持是由编译器增加的，因此如果希望从共享库中获得剖析信息，就需要使用 -pg 来编译这些库。提供已经启用代码剖析支持而编译的 C 库版本（libc_p.a）。 如果需要分析系统函数（如libc库），可以用 –lc_p替换-lc。这样程序会链接libc_p.so或libc_p.a。这非常重要，因为只有这样才能监控到底层的c库函数的执行时间，（例如memcpy()，memset()，sprintf()等）。 gcc example1.c –pg -lc_p -o example1 注意要用ldd ./example | grep libc来查看程序链接的是libc.so还是libc_p.so 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:Prof 模块。你的程序应该以perl -dProf mycode.pl来开始，并使用dprofpp来查看并分析结果。如果你可以用gcj 来编译你的Java 程序，你也可以使用gprof，然而目前还只支持单线程的Java 代码。 　　结论 　　就像我们已经看到的，我们可以使用程序概要分析快速的找到一个程序里面值得优化的地方。在值得优化的地方优化，我们可以将一个程序的运行时从 3分36秒 减少到少于 5秒，就像从上面的例子看到的一样。

iiiiik

	我是个凑数的。。。

asz111

	帮帮顶顶！！

w8899

	谢卖家。三两下就解决了问题

senbza

	作的卖家，就是感觉挺伟大，还有很多的需要麻烦客服，总体感觉很不错~~

mmgg

	老板人非常好

都敏俊系

	不错，而且速度很快，下单后就马上帮忙操作。技术指导很有耐心，满意

a001hao

	很满意，非常有效率，交货很及时，很满意，以后还会再来。