Why profile first: measure where time actually goes

A checkout endpoint is slow. One engineer rewrites the SQL. Another adds Redis. A third runs a profiler for 30 seconds and finds the bottleneck in a JSON serialiser that fires before the database is even touched. Only the third engineer ships a fix.

The principle

Every performance pillar piece downstream — hot paths, GC, N+1, batching, bundle budgets — assumes one habit: you measured before you changed anything. Without that habit, you have a catalogue of optimisations applied to the wrong code.

The principle predates modern profilers. Donald Knuth wrote in 1974: “premature optimisation is the root of all evil — yet we should not pass up our opportunities in that critical 3%.” The full quote names the strategy: identify the 3% of code that actually matters, optimise it, leave the other 97% alone. Identification is the hard part, and the only honest tool for it is measurement.

Why intuition fails

Modern systems are too layered to model in your head: framework, runtime, OS, caches, libraries, network. The function you think is slow is almost never the one that is actually slow. Engineers who skip measurement end up rewriting code that was not the bottleneck. The new code is sometimes prettier, sometimes uglier — but it does not get faster, because the real slow part was somewhere else.

A profile is the infrared camera for code. A cold house: you guess the bedroom window leaks; you seal it. Monday it is still cold. An infrared camera shows the attic hatch is the real leak — 80% of heat escaping through one overlooked gap. Profiling shows where time is actually escaping.

The Bea and Sven scenario

Bea · Browser thinks the slow checkout is the database and rewrites SQL — three joins collapsed into one. Endpoint speed: unchanged. Sven · Origin server attaches a profiler for 30 seconds: 80% of the time is in a JSON serialiser inside a logger that runs before the database is even reached. SQL was 3%. Bea removes the heavy log call; the endpoint drops from 1200 ms to 250 ms.

The lesson is not that database optimisation is useless — it is that the database was not the bottleneck in this case. Only the profile could tell you that.

The measurement loop (overview)

Profile-first is a repeated cycle, not a one-time act.

1. Reproduce the slow scenario under realistic load.
2. Capture a baseline profile — CPU, allocations, or wait time, depending on the symptom.
3. Read the profile — name the top hotspot with concrete numbers: “function X consumes 38% of CPU.”
4. Form one hypothesis about the fix and predict the expected speedup.
5. Apply the fix in isolation.
6. Capture a new profile under the same load and diff against baseline.
7. Ship and watch production metrics to confirm the win held under real traffic.

Skipping step 2 means you cannot prove the fix worked. Skipping step 4 means you cannot tell if you got lucky. Each step is load-bearing.