The Compiler Is Also a Program With Performance Requirements

It is tempting to describe a compiler as fast or slow. There are four axes, they are in tension, and a design that wins on one is usually paying on another.

Compile time — wall-clock for a full build, and separately for one file. Memory — peak resident set, which is the axis that fails abruptly rather than gradually, and which caps how much parallelism you can actually use. Incremental turnaround — the time from a one-line edit to a runnable result, which is the number engineers actually experience. Generated code quality — what all the analysis was for.

The tensions are structural. More analysis costs time and memory and buys code quality. Whole-program and link-time optimization buy code quality by spending all three others at once. An architecture designed for fast incremental rebuilds — fine-grained dependency tracking, persistent caches, a query engine rather than a batch pipeline — pays with substantial complexity and often with a slower cold build, because the bookkeeping is not free. Even memory and time trade directly: caching analysis results makes a pass faster and the process larger, and a compiler that runs out of memory at 32 parallel jobs has effectively lost the time it thought it was buying.

Go is the clearest deliberate position on this table. Its designers accepted a middle-end less aggressive than LLVM's in exchange for a compiler and linker fast enough that a large program builds in seconds, and structured the language — no textual header inclusion, an explicit dependency graph, no cyclic imports — so the compiler is not asked to do the expensive things in the first place. That is a language design choice made for compile time, which is the strongest evidence available that this axis is a first-class concern.

Slow builds have a small number of recurring causes, and the largest are usually not in the optimizer.

Header inclusion. In C and C++ the preprocessor pastes headers textually into every unit that includes them, so a header included by five hundred files is parsed five hundred times, and so is everything it includes transitively. The work is multiplicative in a way nothing else here is, and a single widely included header that grows by a few thousand lines can add minutes to a full build. This is the problem [[modules]] and [[interface-files]] exist to solve, and the reason precompiled headers were invented as a workaround — see [[the-preprocessor]].

Template instantiation. Each distinct set of template arguments produces a fresh instantiation to parse, check and optimize, and instantiations nest. The frontend, not the optimizer, is usually where the time goes, and much of the output is duplicate work that the linker later discards — see [[template-instantiation]].

Monomorphization. The same phenomenon in Rust and in generic C#, and by design: generic code is specialised per concrete type so it can be optimized as if it were hand-written. The compile-time bill is the price of the runtime benefit, and it is what [[monomorphization]] versus [[type-erasure]] is really a decision about.

Link-time optimization. Discussed at length in [[link-time-optimization]]; the relevant fact here is that it converts a parallel build into one large serial memory-hungry step, so its cost is worse than its share of the total work.

Debug information. DWARF for a large C++ program is frequently larger than the code it describes, and generating, writing and linking it is real time and real I/O. It is also, correctly, the last thing anyone should disable — the cost belongs on the list because it is often the surprising majority of a "why is my object file 80 MB" investigation.

And the serial tail. Linking is one process at the end of an otherwise parallel build, so on a large binary it can dominate the critical path however many cores are available. Modern parallel linkers exist specifically because of this.

The reason compile time is a first-class engineering concern is not the wall-clock. It is that the length of the edit-build-test loop determines which work a team is willing to attempt.

At a ten-second loop, the natural unit of work is one small change, verified. People try things. A speculative refactor costs ten seconds to evaluate, so it gets evaluated. Tests run locally because running them is cheaper than reasoning about whether they would pass.

At a fifteen-minute loop, all of that inverts. Changes get batched to amortise the wait, which makes each one larger and harder to review and harder to bisect when it breaks. Local testing is replaced by pushing to CI and context-switching, which means the feedback arrives after the mental state that produced the change is gone. Refactoring stops, because a refactor is a change whose value is only visible once you see the result, and nobody spends fifteen minutes to look at something they might discard. Exploratory work — the printf-debugging loop, the "what happens if" — becomes disproportionately expensive.

None of that shows up on a build-time dashboard. It shows up as larger pull requests, more integration failures, and a codebase that stops being tidied. That is why "make the build faster" is frequently a higher-leverage investment than any optimization the build produces, and why the trade in [[compile-time-vs-runtime]] has to be evaluated with the human side included.

The mechanisms fall into three groups, and they attack different budgets.

Do less work. Skip optional analyses at low optimization levels; use cheaper algorithms where the expensive one's extra precision does not pay — linear-scan register allocation instead of graph colouring in a fast tier, for instance, which is [[linear-scan-allocation]]. Bound pass iteration counts. Cap inlining budgets so a pathological input cannot produce quadratic growth.

Do it once. Cache analysis results within a compile and across compiles. Reuse parsed headers via precompiled headers or a module interface. Deduplicate template instantiations. Memoise queries so that an incremental rebuild recomputes only what actually changed — the architecture behind [[incremental-compilation]], and the reason modern compilers are increasingly structured as demand-driven query engines rather than as batch pipelines.

Do it in parallel. Separate compilation gives per-file parallelism for free, which is [[separate-compilation]]'s underrated benefit. Within a compile, code generation parallelises per function; the frontend generally does not, because name resolution and type checking have genuine ordering dependencies. Parallel linkers attack the serial tail.

The uncomfortable observation is that these mechanisms conflict with the ones that improve generated code. Caching costs memory, which caps parallelism. Whole-program optimization destroys per-file parallelism and incrementality outright. Monomorphization improves generated code by generating more of it to compile. There is no configuration that is best on all four axes, which is precisely why "which compiler is fastest" is not a well-formed question and "fastest at what, on what, and at what cost to the other three" is.