Measure Before Optimizing

Measure Before Optimizing

No optimization without a measurement. Intuition about where time goes is wrong often enough that acting on it produces complexity without speed.

The cycle

1. Measure first. Profile, time, or count queries on a realistic workload. Find the actual hotspot — not the code that "looks slow".
2. State the baseline. "X takes 2.3s, target is under 500ms." Without a number, nothing can be proven later.
3. Fix the biggest cost first. It is usually structural — N+1 queries, O(n²) loops, missing index, repeated work inside a loop, chatty I/O — not micro-level (string concatenation, function call overhead).
4. Re-measure the same workload. Report before/after numbers. Without them, the claim is just "I changed something".

Heuristics

• Batching and killing N+1 patterns beat any micro-optimization by orders of magnitude.
• Cache only with an invalidation story — a stale cache trades a speed problem for a correctness bug.
• Don't trade readability for unmeasured gains; do trade it for a measured 10x.
• Parallelism added "for speed" without measurement usually adds race conditions, not speed.

Red flags

"This should be faster", optimizing in the middle of an unrelated task, preemptive caching or parallelization. All of these mean: measure first, or leave it alone.