从网上整理的关于gprof报“no accumulated time”的原因

Hi.

I am trying to debug a problem with a certain running program, and I've been asked to provide the developer with the gprof output. Unfortunately, when I do this, the timing information is always 0 even though the functions are called thousands of times, and should be greater than 0. It seems to happen with my existing gcc 3.2.2 and binutils 2.13.2 gprof, or if I use a later gcc, 3.4.3 and binutils 2.16. However, when the developer runs the same test on his systems, he sees all of the timings. What would stop the timings from appearing in the gprof output??

Here's an excerp from the profile output:

  %   cumulative   self              self     total
 time   seconds   seconds    calls  Ts/call  Ts/call  name
  0.00      0.00     0.00 20855806     0.00     0.00  po_ctl
  0.00      0.00     0.00 10427903     0.00     0.00  io_wait_dowork
  0.00      0.00     0.00 10427903     0.00     0.00  po_reset
  0.00      0.00     0.00 10427903     0.00     0.00  po_wait
  0.00      0.00     0.00 10427903     0.00     0.00  socket_set
  0.00      0.00     0.00 10427863     0.00     0.00  check_tls_dowork
  0.00      0.00     0.00 10427863     0.00     0.00  multi_process_post
  0.00      0.00     0.00 10427863     0.00     0.00  pre_select

...

Thanks for any assistance you can provide..

Jason Keltz <[email protected]> writes:

> What would stop the timings from
> appearing in the gprof output??
原因一：
If the number of calls is correct, but the times do not appear, I
would suspect the kernel profiling timer, or the profil system call,
or the code in libc which writes out the profiling information.  You
didn't mention what type of system you are using, so it's hard to be
more specific.

Ian

~~~~~~~~~~~~~~
原因二：
In my experience gprof just doesn't work with multithreaded programs.
gprof对多线程不起作用：HOWTO: using gprof with multithreaded applications
http://sam.zoy.org/writings/programming/gprof.html

~~~~~~~~~~~~~~
原因三：
This is way OT for linux-kernel, but here goes:

If you application runs for a very short amount of time (say, less than a
second) the profile will probably be dominated by
glibc startup,
application initializations and
exit routines.
It's useless. That you don't have time accumulated is the least of your problems - even with the times, your profile would be random numbers and random function names.

起码要运行一段时间，否则就会受启动、初始化、退出等库函数运行的影响
In order to profile *anything* - you should make sure that it runs for a while
(I would say minutes at least, but it depends very much on the complexity of
your application, eg. number of functions involved, and how their run-time is
affected by data input and the environment (timing-sensitive threaded
applications etc.)). You simply need a good data sample, otherwise any data
you have will be dominated by noise, and your profile will be random.

If it's a very small computational routine, simply put it in a
   for (int i = 0; i != 100000; i++) { ... }

 不过现在您可能已经注意到了 gprof 的最大缺陷：它只能分析应用程序在运行 过程中所消耗掉的用户时间。通常来说，应用程序在运行时既要花费一些时间来运行用户代码，也要花费一些时间来运行"系统代码"，例如内核系统调用。

--
原因四：www.stanford.edu/class/cme212/profiling.pdf

。。。
这里有一些有趣的东西发生，根据gprof，程序bounce多次调用了函数Bounce和DrawCircle（如上面的calls列所示）但这些函数的运行时期却为0（见上面%time列）。要理解所发生的一切，我们需要事先了解一下gprof是如何工作的。调用某函数的次数是通过计数获得的；编译代码时在命令行加入-pg，就会在程序bounce里添加代码以计算调用各函数的次数。不过计算某个函数内运行所消耗的时间是通过一个采样过程完成的。注意gprof输出的最开始一行标明了采样周期为0.01秒。那么，每0.01秒程序被采样一次，同时计数程序所在的代码被记录一次。不幸的是，对于像bounce这样一个大部分时间都花在库函数调用上面的程序来说，该采样过程工作得并不是很好。

 

为了看清bounce程序把它的时间都花在哪里了，我们转向基于剖析器的simulation--而不是sampling。在此之前，先简要阐述一下gprof的注释功能。用命令"-A"执行gprof，将产生含有"调用次数","时间统计"等注释信息的源代码。