Measure First: The Arithmetic That Decides What to Optimise

Developers are good at reasoning about correctness and bad at reasoning about time, and the gap is structural rather than a matter of skill.

The reasons compound:

• Cost is invisible in the source. One line calling a function looks the same whether that function returns immediately or makes a network call. The code shows structure, not duration.
• Orders of magnitude are unintuitive. A cache hit and a disk read differ by a factor in the thousands, but they occupy one line each, and the eye weights them equally.
• Attention follows complexity. The gnarly algorithm gets suspicion; the innocent-looking loop that calls a getter which lazily reloads a config file does not.
• The hot path is rarely where the interesting code is. Time concentrates in serialisation, allocation, logging and waiting, none of which anyone enjoys reading.

Key idea: the profiler is not a tool for confirming your hypothesis. It is a tool for discovering that your hypothesis was wrong, which it usually is, and the teams that get fast are the ones that check before they change anything.

The cost of guessing is not just wasted effort, and the arithmetic of why is the next step.

There is a hard limit on what improving one part of a system can do to the whole, and it was formalised by Gene Amdahl in 1967 at the AFIPS Spring Joint Computer Conference.

If a component accounts for a fraction p of total runtime and you speed that component up by a factor s, the overall speedup is:

The consequence that matters arrives when you let s go to infinity. Even making the component take zero time leaves the rest untouched, so the best possible speedup is 1 divided by (1 - p).

Key idea: optimising a component that is 10 percent of runtime cannot make the system more than about 1.11 times faster, no matter how brilliant the optimisation. This single fact should govern where effort goes, and it is why the first question is never "how do I make this faster" but "what fraction of the total is this?"

The law becomes useful when it settles an argument that would otherwise be about taste.

In practice: run this calculation before starting, every time. It takes two minutes, needs only a rough profile, and it routinely reverses the plan. The proposal that survives the arithmetic is usually not the one anybody arrived with.

"Make it faster" hides two goals that often pull in opposite directions, and choosing between them changes which optimisations are even correct.

The two genuinely conflict. Batching improves throughput by amortising fixed costs over many items, and it worsens latency because the first item waits for the batch to fill. Adding queueing smooths load and raises utilisation while making every queued request slower. A system tuned for maximum throughput is frequently a system with terrible tail latency, and the reverse holds too.

Gotcha: measure latency as a distribution, never as an average. An average hides the tail, and the tail is what users complain about. The catalogue's observability course covers why percentiles cannot be averaged and why the p99 matters more than it looks, and everything there applies directly to profiling work.

Performance work is a measurement loop, and skipping any step is how teams end up slower after a month of optimisation.

It starts with a goal, because without one there is no way to know when to stop and no way to judge whether a change was worth its complexity. Then a baseline: measure the current behaviour under realistic conditions, and record it somewhere durable.

Profiling identifies where time actually goes, and the arithmetic from earlier in this lesson decides which of those places is worth attacking. Only then does a change get made, and it must be one change, because two simultaneous changes cannot be attributed.

Measuring again either confirms an improvement or does not, and the honest response to "no improvement" is to revert. An optimisation that did not help is not neutral: it is complexity added for nothing, and it will be maintained for years by people who assume it was necessary.

Key idea: the loop's discipline is that every change is a hypothesis with a measurement attached. Without the before-and-after pair, you have not optimised anything, you have merely changed the code and formed an opinion.

"Faster" is not a goal, because it has no end. A usable target has three parts, and writing them down before starting is what prevents optimisation from becoming an open-ended activity.

• A metric with a percentile. Not "the search endpoint", but "the p95 of the search endpoint".
• A number and a condition. Under 300 ms, at the peak traffic we actually see, with production-shaped data.
• A reason. Because the SLO says so, because conversion drops beyond that point, because the upstream timeout is 500 ms and we need headroom.

The third part is the one usually missing, and it is what makes the target defensible when someone asks why not 200 ms.

In practice: performance work has sharply diminishing returns, and a target is what lets you notice you have reached them. The first afternoon typically finds something large and obvious; the second week is fighting for percentages against code that is now harder to read. Without a stated target, nothing signals when the trade stopped being worth it, and the codebase quietly accumulates cleverness nobody can safely modify.

With the goal set and the arithmetic understood, the question becomes how to find where the time is actually going, which is what a profiler is for.

The measure-first rule has real exceptions, and knowing them prevents the discipline from becoming a ritual.

Algorithmic complexity is a design decision, not an optimisation. If a lookup is a linear scan through a list that will hold a million entries, you do not need a profiler to know it belongs in a hash map. Choosing the right data structure up front costs nothing and is not premature.

Known-expensive operations in a loop. A network call, a database query or a file read inside an iteration is a defect whether or not it currently shows in a profile, because the profile reflects today's data volume.

Obvious waste. Work computed and discarded, results recomputed instead of held, debug logging left at full verbosity in a hot path.

Gotcha: Knuth's remark about premature optimisation being the root of all evil is routinely used to justify shipping an accidentally quadratic algorithm. It was never an argument against thinking, only against micro-tuning code whose cost nobody has established. Choosing an appropriate algorithm is design; hand-unrolling a loop before measuring is the thing being warned about.

The honest boundary is whether you know the cost or are guessing at it. Known-bad patterns can be fixed on sight. Everything else needs evidence, and the next lesson is about how that evidence is produced.