构建链接到未使用的库的gcc的系统性能影响 [英] build system performance impact of gcc linking to unused libraries

问题描述

我有一个类似于以下的代码库：

来源：

  src / a / b / c.cpp 
  

和单元测试（这些实际上是提升单元测试可执行文件）：

  test / a / b / c_test.cpp 
  

src 树用于单个可执行目标。然而， c.cpp 仅使用该目标的库依赖关系的子集，例如， -lx ， -lx -ly -lz 。

<同样， c_test.cpp 编译为一个测试可执行文件，它链接到c.cpp的 -lx ， co <​​/ code>和其他一些额外的库进行测试。

为了设置构建系统，在这种情况下，我有两个选项：

1. 将构建系统中的每个此类可执行文件与其自己的库依赖项列表配对。 （痛苦，但也许可以通过映射头依赖 - >库来自动化。）


2. 或者，对所有测试可执行文件和主要可执行文件使用相同的库列表。 （简单，无痛的方式）。
   

什么是＃2的构建系统性能影响在大？它真的很重要吗？

$杂项：
这与g ++（Debian 4.9.1-16）4.9.1

解决方案

这个真正的答案取决于这些库是什么，但总的来说，我会说可能没有什么大的影响，除非库很大。这是问题的实际使用的库，特别是如果它们很大，因为库中的所有代码都必须被复制。

我只是做了一个小实验，并编译了一个Hello World程序（使用 clang ++ ，但它在后端使用相同的链接器，无论您使用 clang ++ 或 g ++ ，默认库为编译器提供的。最好的时间为0.232s（第一次，因为必须读取编译器从磁盘花费大约2秒钟）。

然后，我添加了 llvm-config --libs （所以库你需要当你使用llvm编译器框架时）。这变成了这个：

  -lLLVMLTO -lLLVMObjCARCOpts -lLLVMLinker -lLLVMipo -lLLVMVectorize -lLLVMBitWriter 
 -lLLVMIRReader -lLLVMAsmParser -lLLVMTableGen -lLLVMDebugInfo -lLLVMOption 
 -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG 
 -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info 
 -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMLineEditor 
 -lLLVMInstrumentation -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMCodeGen 
 -lLLVMScalarOpts -lLLVMProfileData -lLLVMObject -lLLVMMCParser -lLLVMBitReader 
 -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget 
 -lLLVMMC -lLLVMCore -lLLVMSupport 
  

那，当链接时，使我的编译器项目成为一个好的100MB的可执行文件。

与hello world程序的编译时间差异大约为0.04s。

只会保持简单并保持一个库的单一列表。

然而，我会补充说它取决于文件的位置。如果您要在非常慢的文件服务器上链接一堆文件，则可能需要更长的时间才能阅读该库包含的内容。

I have a code-base similar to the following:

sources:

src/a/b/c.cpp

and unit-tests (these are actually boost unit-test executables):

test/a/b/c_test.cpp

The src tree is used in a single executable target. However c.cpp only uses a sub-set of the library dependencies of that target, e.g. -lx, of -lx -ly -lz.

Similarly, c_test.cpp compiles to a test executable that links to c.cpp's -lx,c.o and a few more additional libraries for testing.

For setting up the build-system, in this case I have two options:

1. Pair each such executable in the build-system with its own library dependency list. (Painful, but perhaps could be automated by mapping header dependency -> library.)
2. Or, just use the same library list for all test executables and the main executable. (The easy, painless way).

What is the build-system performance impact of #2 "in the large"? Does it really matter?

Misc: This is with g++ (Debian 4.9.1-16) 4.9.1

解决方案

The answer to this REALLY depends on what those libraries are, but in general, I'd say "probably no big impact, unless the libraries are huge". It is libraries that are ACTUALLY USED that is the problem, particularly if they are large, because all the code from the library has to be copied in.

I just did a small experiment, and compiled a "Hello World" program (using clang++, but it uses the same linker at the backend whether you use clang++ or g++, with the default libraries as per the compiler provides. It took 0.232s as the best time (the first time, because the compiler had to be read from disk took about 2 seconds).

I then added the llvm-config --libs (so the libraries you need when you use the llvm compiler framework). Which turns into this:

-lLLVMLTO -lLLVMObjCARCOpts -lLLVMLinker -lLLVMipo -lLLVMVectorize -lLLVMBitWriter
-lLLVMIRReader -lLLVMAsmParser -lLLVMTableGen -lLLVMDebugInfo -lLLVMOption 
-lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG 
-lLLVMAsmPrinter -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info 
-lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMLineEditor 
-lLLVMInstrumentation -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMCodeGen 
-lLLVMScalarOpts -lLLVMProfileData -lLLVMObject -lLLVMMCParser -lLLVMBitReader 
-lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget 
-lLLVMMC -lLLVMCore -lLLVMSupport

That, when linked in, makes my compiler project into a good 100MB of executable file.

The difference in compile time with the "hello world" program was around 0.04s.

So, I would just keep it simple and maintain one single list of libraries.

I would add however that it does depend on where the files are located. If you are linking against a bunch of files on a very slow file-server, it may take a bit longer to read the "what does this library contain".

这篇关于构建链接到未使用的库的gcc的系统性能影响的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！