我刚用gprof来分析我的程序。我想看看哪些功能消耗的CPU时间最多。但是，现在我想以不同的方式分析我的程序。我想看看消耗最多CPU时间的代码LINES。起初，我读到gprof可以做到这一点，但我找不到合适的选项。
现在，我找到了gcov。但是，我尝试执行的第三方程序没有“./configure”，因此我无法应用“./configure --enable-gcov”。
我的问题很简单。有谁知道如何为我的程序获得每行代码的执行时间？
（我更喜欢gprof的建议，因为我发现它的输出非常容易阅读和理解。）
答案 0 :(得分：4)
我认为oprofile就是你要找的。它执行基于统计的抽样，并为您提供在C抽象级别和汇编代码级别执行每行代码所花费的时间的近似指示。
除了简单地分析每行所花费的相对周期数之外，您还可以检测其他事件，如缓存未命中和管道停滞。
最重要的是：您不需要为分析做特殊构建，您只需要启用调试符号。
以下是对oprofile的一个很好的介绍：http://people.redhat.com/wcohen/Oprofile.pdf
答案 1 :(得分：1)
如果您的程序执行时间不长，Valgrind/Callgrind + KCacheGrind + [打开调试时编译（-g）]是如何判断某个位置的最佳方法之一程序在用户模式下运行时花费时间。
valgrind --tool=callgrind ./program
kcachegrind callgrind.out.12345
程序应在要优化的部件中具有稳定的IPC（每个时钟的指令）。
缺点是Valgrind不能用于测量I / O延迟或分析内核空间。此外，使用与C / C ++工具链不兼容的工具链的编程语言的可用性是有限的。
如果Callgrind对整个程序的检测需要花费太多时间来执行，那么有CALLGRIND_START_INSTRUMENTATION和CALLGRIND_STOP_INSTRUMENTATION宏。
在某些情况下，Valgrind需要具有调试信息的库（例如/usr/lib/debug/lib/libc-2.14.1.so.debug），因此您可能需要安装提供调试信息文件的Linux软件包，或者在打开调试的情况下重新编译库。
答案 2 :(得分：0)
oprofile 可能是最佳答案。
但是，在编译-pg - ed软件时强制编译器或编译器标志（例如gprof进行autoconf分析）的技巧可能是
CC='gcc -pg' ./configure
或
CFLAGS='-pg' ./configure
这对于一些较新的编译模式也很有用。例如， gcc 4.6 提供链接时间优化，并在编译和链接处传递-flto标记>;启用它，我经常做
CC='gcc-4.6 -flto' ./configure
对于未自动配置但仍使用合理Makefile构建的程序，您可以编辑Makefile或尝试
make CC='gcc -pg'
或
make CC='gcc -flto'
通常（但并不总是）工作。