Profile before optimising

Goal

Spend optimisation effort only where measurement shows it matters, and prove the improvement with the same measurement.

Prerequisites

A representative workload that can be run repeatedly, and a profiler for the language (cProfile for Python, sampling profilers for compiled code).

Steps

1. Define the metric (wall time of a request, throughput, memory peak) and record a baseline with several runs; note the variance.
2. Profile the workload. Use a sampling profiler or flame graph for a whole-program view, and a deterministic profiler such as cProfile for detail on a suspected area.
3. Read the profile for the largest self-time or the widest flame; check whether it is algorithmic (wrong complexity), I/O bound (waiting) or overhead (allocation, serialisation).
4. Change one thing, re-measure against the baseline, and keep the change only if the metric improves meaningfully.
5. Add a benchmark or a performance test for the improved path so that regressions are noticed.

Expected result

A documented before/after measurement for every optimisation, and code that stays simple where speed does not matter.

Limits and test basis

Profilers perturb timing, especially deterministic ones; sampling profilers are safer for production. Microbenchmarks can mislead when the real workload differs. The tools named are examples from the cited documentation.