perflisted

# Perf Performance work has one rule: measure first. Intuition about where time goes is usually wrong. Profile before optimizing, or you'll spend time speeding up code that isn't the bottleneck. ## The performance investigation workflow 1. **Define the problem precisely.** "Slow" is not a specification. What's the current latency at p50, p95, p99? What's the target? Under what load? Without a number, you can't tell if you've improved anything. 2. **Reproduce it.** Find a request, a data set, or a load pattern that reliably triggers the problem. If you can't reproduce it, you can't fix it or verify the fix. 3. **Profile, don't guess.** Run the workload under a profiler and read the flame graph or call tree. The hot path is where to look — not the code you wrote most recently, not the code that looks most suspicious. 4. **Fix the biggest thing first.** A 40% improvement on a function that takes 5% of total time is a 2% overall win. A 20% improvement on the function that takes 70% of total time is a 14% win. Work top-down on the profiler output. 5. **Measure after each change.** Don't batch optimizations and measure once at the end — you won't know which change did what, and you risk optimizing away something that was actually hurting you elsewhere. ## Database / data access This is the most common bottleneck in web applications. Check here first. **N+1 queries**: executing one query to get a list, then one query per item. Symptoms: query count per request scales linea