使用gcc/g++和ld进行配置文件链接的时间

Question

我正在使用g++编译和链接一个包含大约15个C ++源文件和4个共享对象文件的项目。最近链接时间增加了一倍以上，但我没有可用的makefile历史记录。有没有办法对g ++进行剖析，以查看哪部分链接需要很长时间？

编辑：在注意到makefile始终使用-O3优化之后，我成功地通过删除该开关将链接时间减半。有没有什么好方法可以在不试错的情况下找到这个问题？

编辑：实际上，我并不想对ld的工作方式进行剖析。我想知道如何将链接时间的增加与特定的命令行开关或对象文件匹配。

- Nathan Fellman

Answer 1

性能分析g++是没有意义的，因为链接由链接器ld执行。

性能分析ld也不会显示任何有趣的东西，因为链接时间通常受磁盘I/O的影响，如果您的链接不是这样，您将不知道如何处理性能分析数据，除非您了解ld内部工作原理。

如果只有15个文件进行链接就已经很明显，那么您的开发系统可能存在问题[1]；要么它的磁盘已经快挂了并且在不断重试，要么您的系统内存不足以执行链接（链接通常需要大量RAM），导致您的系统频繁交换。

假设您使用的是基于ELF的系统，则可以尝试新的gold链接器（binutils的一部分），它通常比GNU的ld快几倍。

[1] 我通常会链接数千个对象，生成200多MB的可执行文件，而且在60秒内完成。

- Employed Russian

Answer 2

如果您刚刚达到了RAM的限制，您可能能听到磁盘正在工作，系统活动监视器会告诉您这一点。但如果链接仍然受CPU限制（即，如果CPU使用率仍然很高），那么这不是问题所在。如果链接受IO限制，最常见的罪魁祸首可能是运行时信息。无论如何，请查看可执行文件大小。

用另一种方式回答您的问题：您是否正在进行大量的模板使用？对于每个使用具有不同类型参数的模板，都会生成整个模板的新实例，因此您需要为链接器做更多的工作。不过，要真正注意到这一点，您需要使用一些非常依赖于模板的库。Boost项目中的许多库都符合条件-当我使用具有复杂语法的Boost::Spirit时，基于模板的代码膨胀。并且，编译了约4000行代码，生成了7.7M的可执行文件-更改一行代码会使所需的专业化数量和最终可执行文件的大小加倍。不过，内联帮助很大，输出为1.9M。

共享库可能会引起其他问题，您可能需要查看-fvisibility=hidden的文档，并且它将改善您的代码。来自GCC手册的-fvisibility：

 Using this feature can very substantially
 improve linking and load times of shared object libraries, produce
 more optimized code, provide near-perfect API export and prevent
 symbol clashes.  It is *strongly* recommended that you use this in
 any shared objects you distribute.

实际上，链接器通常必须支持应用程序或其他库覆盖库中定义的符号的可能性，尽管这通常不是预期的使用方式。请注意，使用它并非免费，它需要（微不足道的）代码更改。

文档建议的链接是：http://gcc.gnu.org/wiki/Visibility

- Blaisorblade

Answer 3

gcc和g++都支持-v详细标志，这使它们输出当前任务的详细信息。

如果您真正想要对工具进行分析，您可能需要查看Sysprof或OProfile。

- codelogic