从网上整理的关于gprof报“no accumulated time”的原因
2008-12-23 23:17
316 查看
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 <jas@cs.yorku.ca> 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,将产生含有"调用次数","时间统计"等注释信息的源代码。
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 <jas@cs.yorku.ca> 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,将产生含有"调用次数","时间统计"等注释信息的源代码。
相关文章推荐
- 关于Hibernate中No row with the given identifier exists问题的原因及解决
- 整理网上的一些关于sharepoint编码方面的最佳实践
- 关于Time Limit Exceeded可能的原因
- 关于No such file or directory的一种原因
- 整理网上的一些关于sharepoint编码方面的最佳实践
- 关于网站安全产生原因触发点漏洞表现解决方式的整理
- 关于shell脚本提示No such file or directory的解决办法和原因
- 关于SEO优化方案(网上整理的资料)
- 关于MOS功率与选型,网上资料的整理
- 从网上整理了一些关于比较时间大小和请求网络时间的代码,在这里展示一下
- 关于html中meta的作用(网上搜集整理得来)
- 关于困扰已久的ADO ERROR: Unspecified error" (error code = 0x80004005)问题的原因(网上摘录)
- 在网上整理的关于打开相机和相册并设置成头像的问题
- 关于“no cfi table found”的原因总结
- linux下 关于“No space left on device的原因”
- 关于面试经常被问到的socket的TIME_WAIT状态的原因及解决办法和避免的办法
- 关于搜索中,从一个时间点到另一个时间点的sql,网上的太乱,而且逻辑很复杂,个人整理了一下
- 整理网上的关于 路径遍历漏洞
- IOS中自己关于Ivar和objc_property_t的理解,整理下网上资料
- 关于如何提高sql语句执行效率(网上整理)