C:分析C程序的瓶颈
Posted
技术标签:
【中文标题】C:分析C程序的瓶颈【英文标题】:C: analyze bottleneck of C programs 【发布时间】:2011-12-10 17:36:56 【问题描述】:我的 C 程序对效率至关重要。有些函数被调用了数百万次,所以我想知道每个函数花费了多少时间,给我这样的东西:
Total time: 100s
forward(): 20s;
align(): 15s;
...
others: 1s.
是否有任何调试器可以执行此类分析?我在 Ubuntu 上使用 Eclipse CDT,并使用 gdb 进行调试。有人建议Valgrind,但我没有找到合适的。我发现有一些关于 c# 或 php 或 perl 分析的问题,对 C 有什么建议吗?谢谢。
=============================================
跟进:非常感谢大家的帮助,gprof 看起来真的很不错。这是一个手动链接:http://www.cs.utah.edu/dept/old/texinfo/as/gprof_toc.html。
关于解释摘要的问题:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls us/call us/call name
61.29 9.18 9.18 bwa_print_sam_SQ
21.96 12.47 3.29 bwt_sa
4.01 13.07 0.60 bns_coor_pac2real
3.87 13.65 0.58 bwt_match_exact_alt
2.60 14.04 0.39 bwa_read_seq
1.00 14.19 0.15 bwt_match_gap
0.80 14.45 0.12 seq_reverse
如果我没记错的话,它说函数 bwa_print_sam_SQ 占用了总时间的 61.29%。但是我的程序运行了 96.24 秒,这个函数应该运行 60 秒左右。为什么“累积”秒数列只有 9.18?手册说:
cumulative seconds
This is the cumulative total number of seconds the computer spent executing this functions, plus the time spent in all the functions above this one in this table.
而我用的是参数
"gprof -f pe_sai2sam_se_core -f bwa_print_sam_SQ -f seq_reverse ./peta > gprof",
函数“pe_sai2sam_se_core”在一个大的while循环中调用“bwa_print_sam_SQ”。为什么报告说:
index % time self children called name
<spontaneous>
[1] 61.3 9.18 0.00 bwa_print_sam_SQ [1]
-----------------------------------------------
<spontaneous>
[8] 0.8 0.12 0.00 seq_reverse [8]
-----------------------------------------------
它没有说任何关于 pe_sai2sam_se_core... 为什么?
【问题讨论】:
valgrind 和kcachegrind 相当不错。 企业版的 Visual Studio 包括一个分析器。 Glowcode 和其他一些存在,只需在此处本地搜索分析器并享受。 【参考方案1】:您不需要调试器。您需要的称为分析器。既然你提到了 Ubuntu,你可能想以gprof
开头。
这里是你如何使用gprof
:
-O0
) - 当然是可选的
添加 -g
和 -pg
标志
像往常一样重建并运行程序
此时您的程序应该已经在 cwd 中生成了一个gmon.out
文件
使用gprof
检查数据:
gprof ./your_program > prof
现在您可以查看prof
文件。它从平面配置文件开始,它简单地告诉您它在各种功能上花费了多少时间。
【讨论】:
@Cai Shaojiang:gprof 经常会产生误导,在 SO 上搜索其他分析器工具。 只是好奇,为什么-O0
?分析未优化的代码似乎很奇怪。
@HenkHolterman 防止编译器乱来。前段时间我想知道一个什么都不做的函数怎么会使用70%的时间。它所做的只是调用一些甚至没有出现在配置文件中的函数。这应该很明显,但它不适合我。编译器是内联的东西。所以,鉴于那个故事,我总是担心编译器会在我背后做一些令人讨厌的事情,这会让分析器感到困惑。无论如何,我编辑了我的答案。
但现在您可能会看到编译器可以轻松解决的“瓶颈”。
回答这个问题:我总是使用 gprof。 Valgrind 还有一个名为 Callgrind 的插件(或模块,我不确定他们如何称呼他们的附加组件 - 啊!另一个词!),人们经常推荐它。但是我发现它很难使用,并且并不真正理解对这种复杂的分析器输出的需求(也许它在多线程运行时或动态代码中有更好的用途)。 gprof 的一个缺点是它存在于您的二进制文件中,它的代码不一样。 Valgrind 是一个运行你的(完整的)代码的虚拟机。以上是关于C:分析C程序的瓶颈的主要内容,如果未能解决你的问题,请参考以下文章