Tips on reducing c++ linking time

Question

I have a project that takes about 8 seconds to link with g++ and ld.

It uses a bunch of static libraries, most of the code is c++.

I'm interested in a general list of tips on how to reduce link time. Anything from "dont include debug symbols" to "make your code less spagetti"

Illogicality

Are you using link time code generation? It will produce faster code but link times will go up. – Tiebout

8 seconds is fast. That doesn't sound like much to worry about. How big is the project? – Gamester

Platform and compiler? With GCC and binutils, gold is mostly faster than (classic) ld, and clang may (or may not be) faster than that. – Philous

I can do a full build and link of my project with around 800,000 LOC in about 10 seconds. – Extroversion

.8 million lines of code in 10 seconds? I've got single translation units which take longer than that! – Tiebout

Answer 1

I dealt with this for years at a previous job. The GNU linker simply has serious performance problems when linking large numbers of static libraries. At one point, link time was on par with compile time, which we found so strange we actually investigated this and figured it out.

You can try to merge your static libraries into a "super-object" before linking. Instead of linking like this:

$ g++ -o program program.o $STATIC_LIBS

You could try this:

$ ld -r -o libraries.o --whole-archive $STATIC_LIBS
$ g++ -o program program.o libraries.o

Note that this method gives the linker less opportunity to exclude unused object code, so your binaries may increase in size somewhat.

Admit

If you use this method for c++ code, you might need the -Ur switch instead of -r (see the documentation for ld) – Alabama

Is there an osx solution for -Ur for c++ code? it seems ld on osx10.6 does not recognize -Ur – Illogicality

Seeing this I wonder if linking dependencies first would give improved performance. – Hemicycle

Answer 2

create a ramdisk ,compile to that and link to harddisk.

since you're using a lot of static libraries ,you can create a giant library containing all thos libraries so you end up with one libray. remove all libraries from your lib-list and add th giant one. This reduces openings of file to 1 for the libraries and may speed up reading actions.

Warison

Isn't ramdisk that thing we used back in the 1980s? – Alabama

@anatolyg: Yes ,but it still beats harddisks. – Warison

Answer 3

Turn off whole program optimization (at least during development). Use p-impl to reduce dependencies.

Unloosen

isn't p-impl supposed to reduce compile time? – Timer

@Simone: p-impl means that changes in one class's implementation require recompiling only that single compilation unit instead of all consumers. Fewer compilation units changed makes incremental linking more effective. – Unloosen

Answer 4

8 seconds is pretty fast, unless you're really sure that it shouldn't take that long. I've got projects that take 5-8 minutes for a full relink since we don't do incremental linking on our release builds. Have you tried using incremental linking (if you're not using -shared, you can use -i or -r)?

Readus

5-8 minutes still looks like a gazelle. – Tarantass

@Martin: Not so, i work on a 1.2mill LOC c++ codebase, that uses Boost, GMP and some other nasty libraries, using good design, discc (8 servers), fast disks etc, a full build of the entire codebase (including tests) takes around 2-2.5mins using gcc 4.4 - So for something to take 8mins, that would have to be a really really poorly written or huge codebase. – Cycloid

Answer 5

Use mold

The project: https://github.com/rui314/mold .

You can see the benchmarks there.

Installation: (on Debian-like systems): sudo apt install mold

You can use g++ -B/usr/libexec/mold ⟨arguments⟩ as described in https://www.productive-cpp.com/using-the-mold-linker-for-fun-and-3x-8x-link-time-speedups/ , but personally I just make a symbolic link to mold in /usr/local/bin.

It is as expected very fast: for me, originally linking cc1plus (while I build gcc) takes 12 seconds, with mold it takes less than a second.

Echelon

Answer 6

How about compiling debug builds as shared libraries? That will solve the debug symbol bloat, as the import libraries are tiny with or without debug info. Maybe not the best solution, but I think this will cut down link time substantially...

Item

He said specifically that shared libraries were out. And I agree with him - on modern systems, shared libraries add a lot of potential issues and give you few advantages. – Careaga

@TomSwirly Nowhere can I see he mentions being against shared libraries. – Item

Answer 7

You could try using clang and lld. From godot docs

You can also use Clang and LLD to build Godot. This has two upsides compared to the default GCC + GNU ld setup:

LLD links Godot significantly faster compared to GNU ld or gold. This leads to faster iteration times.

Pyrophoric