Performance Engineering

Measure first, change one meaningful bottleneck, then measure again.

Workflow

1. Define the user/system symptom and target metric: latency percentile, throughput, startup time, memory, CPU, IO, battery, or unit cost as appropriate.
2. Establish a representative baseline and workload. Avoid synthetic microbenchmarks that do not exercise the reported bottleneck.
3. Profile or instrument enough to localize the dominant cost before proposing optimization.
4. Form a hypothesis and change the smallest meaningful factor.
5. Re-measure under comparable conditions and check counter-metrics/correctness.
6. If the problem is load/headroom rather than code-path efficiency, model demand, capacity units, scaling trigger, and cost without assuming a provider.
7. Preserve readability/reliability unless the measured gain justifies the complexity.

Stop

Stop when the target symptom has before/after evidence, the bottleneck/result is understood, and remaining tradeoffs are explicit.

Reference Guide