making-it-fasterlisted

# Making it faster Nearly all optimisation work that fails, fails for the same reason: it started from a guess about where the time went. Your intuition about a codebase you did not write is worth very little here. The measurement is worth everything. ## Say what "fast enough" is first Write down the number before you start: this page under 200ms at the median, this job under five minutes, this suite under two. Without a target you cannot tell when to stop, and optimisation with no stopping condition eats a week. Ask if it is not given. "Make it faster" is not a target; "the owner is waiting 40 seconds for a build that used to take 10" is. ## Measure the thing people actually wait for - Reproduce the slowness in a way you can run repeatedly, with realistic data. A hundred rows will not show you the problem that appears at a hundred thousand. - Record the baseline: several runs, and the spread, not one number. A change inside the noise is not a change. - Measure end to end first, then break it down. Knowing that one call takes 90% of the time is worth more than any micro-benchmark. ## Find where the time is Use a profiler if the language has one. Failing that, time the stages and narrow — the same halving you would use to find a bug. Look for the shapes that account for most real slowness before looking at anything clever: - **Work repeated in a loop** — a query per row, a file opened per iteration, a request per item. Batch it. - **Doing it more than once**