performance-optimization

## Overview Performance optimization without profiling is guessing. This skill enforces: measure first, optimize the bottleneck, measure again. It prevents wasted effort on non-bottlenecks and ensures optimizations don't regress correctness. ## When to Use - When performance doesn't meet SLO - Before any "performance improvement" PR - When a feature is slow and the cause is unknown - As part of the `/review` workflow for latency-sensitive paths ## Process ### Step 1: Measure the baseline Before touching any code, record: current p50/p95/p99 latency, throughput, error rate under representative load. Without a baseline, you can't prove improvement. ### Step 2: Profile to find the bottleneck Run a profiler, not your intuition: - CPU-bound: CPU profiler (flamegraph) - Memory-bound: heap profiler, allocation profiler - I/O-bound: database query analyzer, network profiler - Web frontend: Chrome DevTools Performance tab, Lighthouse The bottleneck is almost never where you think it is. ### Step 3: Identify the worst offender The single slowest operation in the critical path. Fix that first. Do not optimize non-bottlenecks. ### Step 4: Write a benchmark before optimizing Create a benchmark that isolates the bottleneck and can be run repeatedly. This is your before/after comparison. ### Step 5: Optimize Common patterns: - **Database**: add missing indexes, eliminate N+1 queries, batch reads, use projections (don't SELECT *) - **Memory**: streaming vs loading, lazy evaluation, object pooling - **CPU**: algorithmic improvement, caching, memoization - **Network**: batching, compression, HTTP/2, CDN, edge caching - **Frontend**: code splitting, lazy loading, virtual scrolling, image optimization ### Step 6: Measure the improvement Run the benchmark before and after. Calculate: % improvement in p99, % reduction in resource usage. If the improvement is not measurable, the optimization was not worth the complexity. ### Step 7: Verify correctness Run the full test suite. Performance optimizations frequently introduce bugs. ### Step 8: Document the optimization Record: what was slow, why, what was done, and the measured improvement. Future engineers will need to understand why this code looks unusual. ## Anti-Rationalizations **"I know this is slow — I don't need to profile"** Everyone thinks they know where the bottleneck is. Profilers are always more accurate than intuition. **"This optimization is obvious — I don't need a benchmark"** Without a benchmark, "obvious improvement" is also "unmeasured claim." ## Verification Requirements - [ ] Baseline measured (p50/p95/p99) before any changes - [ ] Profiler output reviewed to identify actual bottleneck - [ ] Benchmark written before optimization - [ ] Improvement measured and quantified (not "feels faster") - [ ] Test suite passes after optimization