Hacker News Reader

Comment by Scubabear68 | Hacker News Reader

I find it hard to believe that this post indicates that C++ build times are proportional to included bytes, period.

I haven’t used C++ in quite a while, but aren’t templates a big part of this issue?

It becomes believable when you consider that your own code is just a very tiny appendix dangling off the end of a massive chunk of included data. For instance just including <vector> results in a 24kloc compilation unit of gnarly template code in Clang with C++23:

https://www.godbolt.org/z/G18WGdET5

...add <string> and <algorithm> and you're at 45kloc:

https://www.godbolt.org/z/Whv73YPYh

...and those numbers have been growing steadily by a couple thousand lines in each new C++ version.

Multiply this with a few thousand source files (not atypical with the old 'clean code' rule to prefer small source files, e.g. one file per class), and that's already dozens to hundreds of million lines of code the compiler needs to process on a full rebuild, all spent on compiling <vector> over and over again.

TL;DR: the most effective way to improve build times in C++ is to split your project into few big source files instead of many small files (either manually, e.g. one big source file per 'system', or let the build system take care of it via 'unity' or 'jumbo' builds).

Except that doesn't improve the time of iterative builds, which are the only ones that really matter to software development.

It does though for header changes, which then may trigger fewer source file compilations. IME in incremental builds the most time is spent in the linker anyway.

> which are the only ones that really matter to software development.

Debatable in this age of cloud CI builds ;)

> IME in incremental builds the most time is spent in the linker anyway.

A lot of time is spent in the linker because the linker needs to parse and deduplicate any monomorphized C++ classes (like vector). This takes time proportional to the number of compiled copies of the class / function that are kicking around.

So I'd expect linking times to also decrease if you're compiling fewer, larger source files.

Splitting everything in small files makes it so that very little needs to recompile when you change something.

Linking is pretty much just I/O-bound unless you're using LTO. This is assuming you're using a modern linker like mold.

You also need to put into consideration though there are no "small" source files anymore as soon as you include anything from the C++ stdlib. Each tiny source file ends up anywhere between 20 and 100kloc after includes.

Also, many C++ projects I've seen indirectly include almost anything into anything under the hood, so a header change on one end of the project may trigger a rebuild of seemingly unrelated source files.

They're small in the sense that their dependency on the rest of your codebase is small.

Typical solution is to automatically exclude modified files from unity build. So when you edit only 1 cpp you build 2 first time and only 1 afterwards if you need to iterate over it.

Such solution introduces more funny failure modes into build though. People get quite irritated when no change edit in a single file breaks build :)

From a quick test, including every single header in the standard C and C++ library is 180k loc in an otherwise empty .cc file and compiling it with g++13 in C++23 mode takes 1.6s on my machine. Not amazing, but not terrible either.

I also don't believe in tiny instantiation units, but when compiling real code, parsing the headers themselves is not necessarily the bottleneck.

Reply on news.ycombinator.com