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 :)