2

我正在使用 g++ 编译和链接一个由大约 15 个 c++ 源文件和 4 个共享对象文件组成的项目。最近链接时间增加了一倍多，但我没有可用的 makefile 的历史记录。有什么方法可以分析 g++ 以查看链接的哪一部分需要很长时间？

编辑：在我注意到 makefile 一直在使用 -O3 优化之后，我设法通过删除该开关将链接时间减半。有没有什么好方法我可以在没有反复试验的情况下找到这个？

编辑：我实际上对分析 ld 的工作原理并不感兴趣。我有兴趣知道如何将链接时间的增加与特定的命令行开关或目标文件相匹配。

4

3 回答 3

2

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

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

共享库可能会导致其他问题，您可能需要查看 -fvisibility=hidden 的文档，无论如何它都会改进您的代码。来自 -fvisibility 的 GCC 手册：

 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

于 2009-01-12T07:59:27.280 回答
1

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

如果您对真正分析这些工具感兴趣，您可能需要查看Sysprof或OProfile。

于 2008-12-31T20:33:48.827 回答
1

分析g++将证明是徒劳的，因为g++链接器不执行链接ld。

分析ld也可能不会向您显示任何有趣的东西，因为链接时间通常由磁盘 I/O 支配，如果您的链接不是，除非您了解ld内部结构，否则您将不知道如何处理分析数据。

如果您的链接时间很明显，链接中只有 15 个文件，那么您的开发系统 [1] 可能有问题；要么它的磁盘已处于最后阶段并且不断重试，要么您没有足够的内存来执行链接（链接通常是 RAM 密集型的），并且您的系统交换疯狂。

假设您在基于 ELF 的系统上，您可能还希望尝试新的gold链接器（binutils 的一部分），它通常比 GNU 快几倍ld。

[1] 我的典型链接涉及 1000 个对象，生成 200+MB 的可执行文件，并且在不到 60 秒内完成。

于 2009-01-06T08:19:13.770 回答