go-performance

# Go Performance Performance work in Go follows one rule: **measure first**. Intuition about bottlenecks is wrong roughly 80% of the time. Profile, hypothesise, change *one thing*, re-measure. The patterns in this skill apply only on hot paths — premature optimisation makes code worse without making it faster. ## Core Rules 1. **Profile before optimising.** `go test -bench`, `pprof`, `fgprof` — never guess. 2. **One change at a time.** Multi-change "optimisation" passes are unreviewable. 3. **Compare with `benchstat`.** Single runs lie; you need ≥6 runs to see signal. 4. **Allocation reduction usually beats CPU micro-optimisation** — the GC is fast but not free. 5. **Rule out external bottlenecks first.** If 90% of latency is the DB, faster Go code is irrelevant. 6. **Document optimisations in comments.** Future readers will revert "ugly" code without context. ## Iterative Methodology The cycle is: **define goal → write benchmark → measure baseline → diagnose → improve one thing → re-measure → commit with the diff.** ```bash # baseline go test -bench=BenchmarkHotPath -benchmem -count=6 ./pkg/... | tee /tmp/report-1.txt # (apply ONE change) # compare go test -bench=BenchmarkHotPath -benchmem -count=6 ./pkg/... | tee /tmp/report-2.txt benchstat /tmp/report-1.txt /tmp/report-2.txt ``` If `benchstat` shows no statistically significant change, the optimisation didn't work — revert it. Keep the `/tmp/report-*.txt` files as an audit trail; paste the `benchstat` output in th...