principle-performancelisted

# Performance Performance bugs are design bugs. They are cheapest to fix before the first line of code is written. This skill teaches design-time discipline — choosing the right algorithm, data structure, and access pattern — not runtime profiler operation. ## Latency vs Throughput They pull in opposite directions; name the goal before optimizing. - Latency: time to serve one request. Throughput: requests served per unit time. Improving one often degrades the other. - Tail latency (p99, p999) is a separate budget from mean latency — do not let averages hide outliers. - Batching and buffering improve throughput at the cost of per-item latency; state this trade-off explicitly. - Choose the objective first: a real-time API and a batch pipeline have different success criteria. ## Profile Before You Optimize Measurement beats intuition; no fix without a hot path identified by data. - Identify the bottleneck with a profiler before changing code — optimizing a path that accounts for 5% of runtime cannot yield more than a 5% total improvement, no matter how perfect the fix. - Benchmark before and after each change; a "feels faster" claim is not evidence. - Most code is cold; optimize only the identified hot path. Premature optimization is applied to the wrong place. - A profile that surprises you is information; a profile you skipped is a bug waiting to be filed. ## Big-O Where It Bites Algorithmic complexity matters when N grows; the right abstraction is cheaper than any cons