I see it in projects written in languages which aren't any of those. Even C.

Every source file in C corresponds to an object file, and the linker can only exclude unused code if the entire object file is unused. So if you want to optimize your library to for size when linking it statically, it needs to be split up into many source files.

See the musl libc for how that can look taken to an extreme: https://git.musl-libc.org/cgit/musl/tree/src/stdio

The opposite problem, that the compiler can't optimize over object file boundaries, was the impetus behind Link Time Optimization (LTO). But that could also be handled by pasting all the source into one giant file. See SQLite's amalgamation for one example: https://www.sqlite.org/amalgamation.html

> The opposite problem, that the compiler can't optimize over object file boundaries, was the impetus behind Link Time Optimization (LTO). But that could also be handled by pasting all the source into one giant file. See SQLite's amalgamation for one example: https://www.sqlite.org/amalgamation.html

Unity / jumbo builds are not that uncommon but they are not exactly the same as LTO:

1. You no longer have compiler-enforced private intefaces (ie static in C, anonymous namespaces in C++) as everything is a compiltion unit

2. As a consequence of 1. all names must be globally unique. This is less of a problem for new projects, but means you can't just turn on unity builds like you can with LTO.

3. With LTO, parts of the compilation (parsing and initial local optimizations) can be done for each source file and then cached so they don't need to be re-done when another source file changes, allowing faster incremental builds. On the other hand, unity builds allow the compiler to only parse each header once (and for C++ only instantiate templates once for identical parameters), which can significantly speed up (single-core) full builds.

4. Compilers traditionally were mostly single-threader and relied on compiling multiple files in parallel to make use of multi-core CPUs. This approach works with neither LTO nor jumbo builds but with LTO, compiler writers have been working on parallelizing the optimization process itself. The same could have been done with jumbo builds but if you are going to involve compiler modifications anyway, might as well build LTO to avoid 1. and 2.

LTO with a linker plugin (or unity builds with -fwhole-program or equivalent) also covers your size optimization as the compiler can now see which functions go unused.

There are options to the compiler to allow it to remove unused functions, such as placing each function in its own section.