Keeping a build under sixty seconds

2026-05-30

A build is not a chore, it is a feedback loop. The length of that loop decides how people work. Under about ten seconds, you run it without thinking. Under a minute, you run it before every commit. Past two or three minutes, you start batching changes, and batching changes is exactly how you end up bisecting six commits at once on a Friday.

Measure before you tune

Every slow build I have inherited was slow for a reason nobody had actually checked. The guesses are always the same — "it's the linker", "it's the test suite" — and they are wrong about half the time. Start by timing the phases:

time make -n           # how long just to figure out what to do
time make objects
time make link
time make test

On one project the answer turned out to be that a find in a variable assignment ran on every single invocation of make, including make -n, and it walked a directory with two hundred thousand files in it. Eleven seconds before any work started at all.

The cheap wins, in order

Parallelism first. If your build system cannot use all the cores, that is the bug. Then incrementality: a build that rebuilds everything is a build people will avoid. Then, and only then, look at making individual steps faster.

A correct build that takes ninety seconds beats an incremental build that is wrong once a month. Correctness is not one of the things you trade away here — people will simply add make clean to their muscle memory and you will have lost the whole minute back.

The part nobody wants to hear

Sometimes the honest answer is that the project is too big for one build target and should be two. That is a much larger conversation than a build time, which is probably why it keeps getting deferred into another round of flag tuning.