performance-expert

Performance Optimization Expert

Measure, don't guess. Profile to find the real bottleneck, fix the biggest one, re-measure, repeat — and stop at the target. Algorithmic and I/O wins dwarf micro-optimizations.

When to Use

• Something is slow, memory-hungry, or doesn't scale.
• Profiling guidance for CPU, memory, I/O, or rendering.
• Setting/validating latency or throughput targets; benchmarking.
• Hunting a memory leak or GC pressure.

When NOT to Use

• Wrong output, not slow → debugging-expert.
• Behavior-preserving cleanup with no perf goal → refactoring-expert.
• DB query plans/indexing specifically → sql-expert.

Core Principles

1. Measure first, always

• Profile before changing anything. Intuition about hotspots is usually wrong. Optimize the top item the profiler shows, not what you assume.
• Define the metric and target up front (p99 latency, throughput, peak memory, frame time) and a representative workload to measure against. Optimizing the wrong workload wastes effort.
• Beware micro-benchmarks that don't reflect production (warmup, caching, JIT, data size).

2. Biggest levers first

• Algorithmic complexity: O(n²)→O(n log n), removing redundant passes, and killing N+1 calls beat constant-factor tuning by orders of magnitude.
• Eliminate repeated work: cache/memoize pure results, precompute, hoist invariants out of loops, batch requests.
• Apply Amdahl's law: speeding up code that's 5% of runtime caps your win at 5%.

3. Levers by axis

• I/O-bound: batch + parallelize requests, add caching, cut round trips, stream instead of buffering, connection pooling.
• CPU-bound: better algorithm/data structures, reduce allocations in hot loops, vectorize/parallelize, avoid needless serialization.
• Memory: stream large data, fix leaks (lingering refs, unbounded caches, dangling listeners), right-size buffers, reduce per-object overhead.
• Frontend: shrink/split bundles, lazy-load, virtualize long lists, avoid layout thrash and unnecessary re-renders, debounce, use the browser cache/CDN.

4. Verify and guard

• Re-measure after each change to confirm a real win and watch for regressions elsewhere. Stop when you hit the target — over-optimizing adds complexity for no user benefit. Add a benchmark/regression check to prevent backsliding.

Tools

Domain	Tools
Python	cProfile, py-spy, memray, scalene
Node/Web	Chrome DevTools, --prof, clinic, Lighthouse, React Profiler
Go	pprof, go test -bench, -benchmem
Rust/native	perf, flamegraphs, cargo bench, valgrind/heaptrack
DB	EXPLAIN ANALYZE (→ sql-expert)

Common Mistakes

• Optimizing without profiling → effort on cold code; ignore the real hotspot.
• Micro-optimizing (loop unrolling) while an N+1 or O(n²) dominates.
• No baseline/target → can't tell if a change helped or when to stop.
• Premature optimization that obscures code before there's a measured problem.
• Caching without invalidation → correctness bugs; cache deliberately.
• Benchmarking unrealistic data → wins that vanish in production.
• Fixing a symptom in one layer while the cost is elsewhere (e.g., app loop vs DB).

Examples

Profile, then fix the top frame

python -m cProfile -s tottime app.py | head -20   # find the real hotspot
py-spy top --pid <PID>                            # sample a running process

Kill an N+1 with batching

# ❌ one query per id
users = [db.get_user(i) for i in ids]
# ✅ one query
users = db.get_users_in(ids)        # WHERE id IN (...)

See Also

• debugging-expert — same evidence-driven mindset, for correctness.
• sql-expert — query plans and indexing (often the real bottleneck).
• rust-expert / go-expert — low-level profiling and allocation control.
• react-expert — render performance and memoization.