2

我的项目目前有一个静态链接的库（用 gcc 编译并用 ar 链接），但我目前正在尝试用 gprof 分析我的整个项目，我还想在其中分析这个静态链接的库。有什么办法可以做到这一点吗？

Gprof 要求您将 -pg 提供给 GCC 以进行编译，并将 -pg 提供给链接器。但是，当将 -pg 添加到它的标志列表中时，ar 会抱怨。

4

1 回答 1

3

我已经很长时间没有使用 gprof 了，但是 -pg 甚至是 ? 的有效参数ar？如果您使用 -pg 编译所有对象，然后在没有 -pg 的情况下创建归档文件，分析是否有效？

如果你不能让 gprof 工作，gperftools包含一个 CPU 分析器，我认为在这种情况下应该可以很好地工作。您无需使用任何特殊标志编译您的应用程序，也无需尝试更改静态库的链接方式。

在开始之前，您应该注意使用 gperftools 的两个权衡：

  • gperftools 是一个采样分析器。因此，您的结果不会 100% 准确，但它们应该非常好。使用采样分析器的最大好处是它不会真正减慢您的应用程序的速度。
  • 在多线程应用程序中，根据我的经验，gperftools 只会分析主线程。我能够成功分析工作线程的唯一方法是将分析代码添加到我的应用程序中。话虽如此，分析主线程不应该需要任何代码更改。

有很多不同的方法可以使用 gperftools。我的首选方法是使用 加载 gperftools 库$LD_PRELOAD，使用 指定日志记录目标，并可能在启动我的应用程序之前$CPUPROFILE提高采样频率。$CPUPROFILE_FREQUENCY像这样的东西：

 export LD_PRELOAD=/usr/lib/libprofiler.so
 export CPUPROFILE=/tmp/prof.out
 export CPUPROFILE_FREQUENCY=10000
 ./my_application

这会将一堆分析信息写入/tmp/prof.out。您可以运行后处理脚本将此文件转换为人类可读的文件。有很多受支持的输出格式——我最喜欢的是 callgrind：

google-pprof --callgrind /path/to/my_application /tmp/prof.out > callgrind.dat
kcachegrind callgrind.dat &

这应该可以很好地了解您的程序在哪里花费时间。

如果您有兴趣，我在周末花了一些时间学习如何使用 gperftools 来分析 I/O 绑定应用程序，我在这里记录了很多我的发现。与您尝试做的事情有很多重叠，所以也许它会有所帮助。

于 2013-12-05T04:47:18.730 回答