performance-investigationlisted

# Performance Investigation Measure first. Guess never. Fix once. ## Why This Exists Performance intuition is wrong more often than it's right. Developers consistently misidentify bottlenecks — optimizing the wrong function, caching the wrong query, parallelizing the wrong loop. This skill enforces a measurement-first approach that ensures you fix what's actually slow, not what feels slow. ## Phase 1: Baseline Before changing anything, establish a quantitative baseline. 1. **Define the metric.** What specifically is slow? Be precise: - Response time for endpoint X under Y concurrent users - Time to render component Z with N items - Memory usage after processing M records - Build time for the full project "It's slow" is not a metric. "GET /api/users takes 1200ms p95 with 100 concurrent connections" is. 2. **Measure the current state.** Run the measurement 3+ times to confirm it's stable and reproducible. For long-running measurements (>2 min each), 2 runs within 5% of each other is sufficient. Record: - The metric value (with units) - The measurement method (tool, command, conditions) - The environment (machine, load, data size) 3. **Set a target** (if the user hasn't). What would "fast enough" look like? This prevents infinite optimization — you stop when the target is met, not when you run out of ideas. ``` Baseline: GET /api/users → 1200ms p95 (100 concurrent, 10k users in DB) Target: < 300ms p95 Method: wrk -t4 -c100 -d30s http://localh