01 ▸ Workflow Position
[Slow Code]
│
▼
┌─────────────────────────────┐
│ Rob Pike's 5 Rules (ACTIVE)│
│ Measurement & Proof │
└──────────────┬──────────────┘
│
▼
[DONE]
02 ▸ When to use?
Use when the user mentions "optimize", "slow", "bottleneck", "speed up", or anytime you suspect performance issues.
Decision Framework
- You can't tell where a program is going to spend its time. Don't guess — prove it.
- Measure. Don't tune for speed until you've measured.
- Fancy algorithms are slow when n is small (and n is usually small).
- Fancy algorithms are buggier than simple ones. Use simple data structures.
- Data dominates. Choose the right data structures and the algorithms become self-evident.
03 ▸ How it works?
Core Principle: Instrumentation over intuition. The goal is to make sure measurement exists before any optimization continues.
Optimization Checklist
- Check for Instrumentation: Scan for logging, profiling, timing, or APM setup.
- Ask the Measurement Questions: Have I measured? Does one part overwhelm the rest? What's n?
- Block Anti-Patterns: Stop "this loop looks slow" or "let's add a cache" without data.
- Justify Complexity: Simple code that is 10% slower is almost always preferable to fragile "clever" code.
Hard Gates:
- Do not optimize without measurement data showing a specific bottleneck.
- The bottleneck must dominate overall runtime.
- The fix must be the simplest change possible.
- Re-measure after the change to confirm improvement.