与gcc/g ++和ld的配置文件链接时间 [英] profile linking times with gcc/g++ and ld

问题描述

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

I'm using g++ to compile and link a project consisting of about 15 c++ source files and 4 shared object files. Recently the linking time more than doubled, but I don't have the history of the makefile available to me. Is there any way to profile g++ to see what part of the linking is taking a long time?

在我注意到makefile一直在使用-O3优化之后，我设法通过删除该开关将链接时间减半了.如果没有反复试验，有什么好的方法可以找到这个?

After I noticed that the makefile was using -O3 optimizations all the time, I managed to halve the linking time just by removing that switch. Is there any good way I could have found this without trial and error?

编辑:我对配置ld的工作方式实际上并不感兴趣.我很想知道如何匹配增加到特定命令行开关或目标文件的链接时间.

I'm not actually interested in profiling how ld works. I'm interested in knowing how I can match increases in linking time to specific command line switches or object files.

推荐答案

如果您刚达到RAM限制，则可能会听到磁盘工作的声音，系统活动监视器将告诉您.但是如果链接仍然受CPU限制(即，如果CPU使用率仍然很高)，那就不是问题了.而且，如果链接是受IO限制的，则最常见的罪魁祸首可能是运行时信息.还是看看可执行文件的大小.

If you have just hit your RAM limit, you'll be probably able to hear the disk working, and a system activity monitor will tell you that. But if linking is still CPU-bound (i.e. if CPU usage is still high), that's not the issue. And if linking is IO-bound, the most common culprit can be runtime info. Have a look at the executable size anyway.

以另一种方式回答您的问题:您是否正在大量使用模板?对于具有不同类型参数的模板的每次使用，都会生成整个模板的新实例，因此您需要为链接程序做更多的工作.但是，要使该标记真正引人注意，您需要使用一些库，这些库确实占用大量模板资源. Boost项目中的许多内容都符合条件-当使用带有复杂语法的Boost :: Spirit时，我得到了基于模板的代码膨胀.大约4000行代码被编译为7,7M的可执行文件-更改一行将所需的专业化数量和最终可执行文件的大小加倍.内联的帮助很大，导致了190万的输出.

To answer your problem in a different way: are you doing heavy template usage? For each usage of a template with a different type parameter, a new instance of the whole template is generated, so you get more work for the linker. To make that actually noticeable, though, you'd need to use some library really heavy on templates. A lot of ones from the Boost project qualifies - I got template-based code bloat when using Boost::Spirit with a complex grammar. And ~4000 lines of code compiled to 7,7M of executable - changing one line doubled the number of specializations required and the size of the final executable. Inlining helped a lot, though, leading to 1,9M of output.

共享库可能会引起其他问题，您可能希望查看-fvisibility = hidden的文档，无论如何它都会改善您的代码.从GCC手册获取-fvisibility:

Shared libraries might be causing other problems, you might want to look at documentation for -fvisibility=hidden, and it will improve your code anyway. From GCC manual for -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.

实际上，链接程序通常必须支持应用程序或其他库覆盖定义在库中的符号的可能性，尽管通常这不是预期的用法.请注意，使用它不是免费的，但确实需要(琐碎的)代码更改.

In fact, the linker normally must support the possibility for the application or for other libraries to override symbols defined into the library, while typically this is not the intended usage. Note that using that is not for free however, it does require (trivial) code changes.

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

这篇关于与gcc/g ++和ld的配置文件链接时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！