3 ms·
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.
by 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 agoSplitting 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 agoYou 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 agoThey're small in the sense that their dependency on the rest of your codebase is small.