Improving C++ Builds with Split DWARF

In my moderate-sized real-world project (about 700 C++ source files, about 130k lines of code), adding -gsplit-dwarf reduced the time of a single-file recompile+relink from 7.2 seconds to 5.8 seconds, which isn't bad at all for a single extra compiler flag that you never have to think about again (assuming that it works with all your other debugging tools).

But much better than that was switching to using `gold` instead of the regular `ld` (mentioned in the "remarks" section near the bottom of the article); doing this brought my time down substantially further, from 5.8 seconds down to 1.6 seconds. Even without using -gsplit-dwarf, it brought the recompile+relink time down from the original 7.2 seconds to 2.6 seconds.

I guess my codebase might be hitting a particularly bad case for `ld`. I'm kind of startled to see such a large difference for what seemed like a throwaway extra suggestion at the end of the article!

Relatedly, I found it useful to pass -g1 and not just -g to GCC. The resulting debug information is a fair bit smaller and GCC itself also takes less RAM and less CPU time to compile template-heavy code (going from 10s of GB to 1-2 GB on one particularly nasty object file).

13 minutes -> 11 minutes: "Elapsed time goes down by 15%."

3:16 minutes -> 1:42 minutes: "We get a roughly 90% speedup in elapsed time."

What's the formula for the "speedup"? I think it would be more expressive if one would compare it in the same terms.

It might be useful to have things like version-script mapfiles as defining interfaces separate from the actual libraries (ELF objects). Then for shared linking the build system (make, whatever) could notice that though an object changed, its interfaces haven't, and then not re-link dependents.

Is this a new thing? Isn't this like the pdb files that msvc had since the late 1990's?

Just be aware that various downstream dev tools like profilers don't support this very well yet