performancelisted

# Performance ## Iron Law `MEASURE BEFORE OPTIMIZING. MEASURE AGAIN BEFORE KEEPING THE CHANGE.` ## When to Use - Diagnosing slowness, optimizing latency/throughput/allocation, reading profiles, designing benchmarks, investigating p99/p99.9, or deciding whether a performance change is worth it. - Adding, reviewing, tuning, or debugging caches (application, database, Redis/Memcached, CDN, browser, edge), including stale data, stampedes, hot keys, and miss latency. ## When NOT to Use - Concurrency correctness without measured slowness; use `async-systems`. - Database query safety without profiling context; use `database`. - HTTP API cache semantics unrelated to storage or performance; use `api`. ## Core Ideas 1. Name the target metric before changing code. 2. Use a realistic workload and identical before/after conditions. 3. Optimize the measured bottleneck, not the code that only looks suspicious. 4. Tail latency matters; averages hide the slow requests users feel. 5. CPU, off-CPU, memory, allocation, I/O, lock contention, and network wait are different problems. 6. Micro-benchmarks prove local mechanics, not end-to-end wins. 7. Keep complexity only when the measured gain justifies it. 8. Caches need a source of truth, invalidation trigger, stale tolerance, key contract, stampede protection, and metrics before they are kept. 9. Cache keys encode every input that changes the value, including freshness, tenant, permissions, locale, and version. 10.