3 ms·

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

flohofwoe 3y ago
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 ;)
- josephg 3y ago
  > 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.
- mgaunard 3y ago
  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.
  - flohofwoe 3y ago
    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.
    - mgaunard 3y ago
      They're small in the sense that their dependency on the rest of your codebase is small.
SleepyMyroslav 3y ago
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 :)

flohofwoe 3y ago

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

josephg 3y ago
> 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.
mgaunard 3y ago
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.
- flohofwoe 3y ago
  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.
  - mgaunard 3y ago
    They're small in the sense that their dependency on the rest of your codebase is small.

SleepyMyroslav 3y ago

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