Escape analysis

Canonical guidance

• use escape analysis as a diagnostic, not as the whole optimization strategy
• measure allocations before and after changes
• avoid twisting APIs around fragile compiler details without clear payoff

Use when

• heap-allocation investigation
• surprising allocation hot spots
• validating low-level optimization ideas

Avoid

• assuming stack allocation is always worth API complexity
• reading -gcflags=-m output with no benchmark or profile
• micro-optimizing untouched code paths

Preferred pattern

go test -run '^$' -bench . -benchmem
go build -gcflags='-m=2' ./...

Anti-pattern

• rewriting a clear API into pointer gymnastics because one compiler report mentioned an escape

Explanation: This anti-pattern is tempting because compiler diagnostics feel precise, but performance work still needs end-to-end measurement.

Why

• escape analysis is a useful clue, not a substitute for profiling and benchmarking