我的项目目前有一个静态链接的库(用gcc编译并用ar链接),但我目前正在尝试用gprof评测我的整个项目,我也想在其中评测这个静态链接的图书馆。有什么办法可以做到这一点吗?
Gprof要求向GCC提供-pg进行编译,并向链接器提供-pg。然而,ar在将-pg添加到其标志列表中时会抱怨。
我已经很久没有使用gprof了,但-pg甚至是ar
的有效参数吗?如果使用-pg编译所有对象,然后在不使用-pg的情况下创建归档文件,那么评测是否有效?
如果你不能让gprof工作,gperftools包含一个CPU探查器,我认为它在这种情况下应该工作得很好。您不需要使用任何特殊标志编译应用程序,也不需要尝试更改静态库的链接方式。
在开始之前,使用gperftools有两个折衷方案,您应该注意:
- gperftools是一个采样探查器。因此,您的结果不会是100%准确,但它们应该非常好。使用采样探查器并不会真正降低应用程序的速度
- 根据我的经验,在多线程应用程序中,gperftools只会对主螺纹进行仿形加工。我成功的唯一途径评测工作线程是通过将评测代码添加到我的应用程序中来实现的。话虽如此,分析主线程不需要任何代码更改
使用gperftools有很多不同的方法。我的首选方法是用$LD_PRELOAD
加载gperftools库,用$CPUPROFILE
指定日志记录目标,并可能在启动应用程序之前用$CPUPROFILE_FREQUENCY
提高采样频率。类似这样的东西:
export LD_PRELOAD=/usr/lib/libprofiler.so
export CPUPROFILE=/tmp/prof.out
export CPUPROFILE_FREQUENCY=10000
./my_application
这将在/tmp/prov.out中写入一组评测信息。您可以运行后处理脚本将此文件转换为可读文件。有很多支持的输出格式——我最喜欢的是callgrind:
google-pprof --callgrind /path/to/my_application /tmp/prof.out > callgrind.dat
kcachegrind callgrind.dat &
这应该提供一个很好的视图,显示您的程序在哪里花费时间。
如果你感兴趣的话,我在周末花了一些时间学习如何使用gperftools来评测I/O绑定的应用程序,我在这里记录了很多发现。你想做的事情有很多重叠,所以也许这会有所帮助。