Principle: Measure before optimizing

Developers optimize based on intuition, spending time on code that isn't actually the bottleneck. The real hotspot is somewhere else entirely.

Always profile before optimizing:

1. Establish baseline metrics:

- Response time (p50, p95, p99)
- Throughput (requests/second)
- Resource usage (CPU, memory, disk I/O)

1. Profile to find the bottleneck:

# Python:
python -m cProfile script.py
# Or: py-spy top --pid <PID>
# Or: scalene script.py (CPU, GPU, memory profiler)

# Node.js:
node --prof app.js
# Or: clinic doctor -- node app.js
# Or: Chrome DevTools Performance tab

# Go:
import _ "net/http/pprof"
go tool pprof http://localhost:6060/debug/pprof/profile

# Database:
EXPLAIN ANALYZE <query>;

1. Optimize the actual bottleneck:

- Is it CPU? -> Algorithmic improvement
- Is it I/O? -> Caching, batching, async
- Is it memory? -> Data structure changes
- Is it network? -> Reduce calls, compression

1. Measure the improvement:

- Same benchmark, same conditions
- Quantify: '200ms -> 50ms (75% reduction)'
- Ensure no regressions elsewhere

1. Common mistakes:

- Optimizing cold code (runs once at startup)
- Micro-optimizing when the bottleneck is I/O
- Adding caching without measuring cache hit rate
- Optimizing for best case instead of p99

Amdahl's Law: If a component is 5% of total time,
making it infinitely fast only saves 5%.

Profiling replaces guessing with data. The bottleneck is almost never where you think it is, so measure first.