Go Performance
This skill is about measurement-first optimization in Go.
When to activate
Use this skill when you need to:
- Confirm a performance regression (latency/throughput/CPU/memory)
- Identify hot paths with pprof (CPU / heap / mutex / block)
- Reduce allocations and GC pressure in a measured hotspot
- Fix contention (mutex, scheduler, channel backpressure)
- Validate improvements with benchmarks and repeatable runs
If you need general idioms and patterns (not measurement), use golang-patterns.
Rules of engagement
- Profile before optimizing. A fast guess beats a slow change.
- Change one thing at a time. Measure after each change.
- Keep a baseline. Every claim should have “before vs after”.
- Don’t optimize the cold path. Make the hot path boring.
Outcome expectations
- Performance claims are backed by reproducible before/after measurements.
- Profile type selection matches the observed symptom.
- Optimizations are incremental, attributable, and regression-resistant.
Workflow
Make it measurable
- Add a benchmark (or a reproducible load test) for the suspected hotspot.
- Run multiple iterations; record mean + variance.
Capture evidence
- CPU profile for time
- Heap/allocs profile for memory
- Mutex/block profiles for contention
- Trace when the scheduler / GC behavior matters
Analyze before changing code
- Identify top offenders (
top, top -cum)
- Inspect annotated source (
list)
- Confirm whether you are bound by CPU, allocations, syscalls, or contention
Apply targeted fixes
- Allocation and GC: reduce allocations, reuse buffers, avoid retaining large backing arrays
- Data layout: improve locality, avoid interface boxing in hot loops
- Concurrency: reduce contention, bound goroutines, add backpressure
Verify and document
- Re-run the benchmark/profile
- Ensure correctness isn’t traded away
- Record the change and its measured impact
Symptom to first profile mapping
- High CPU -> CPU profile
- Memory growth -> heap profile (compare snapshots)
- High allocation churn / GC pressure -> allocs profile
- Latency spikes without CPU spike -> block profile
- Lock contention suspicion -> mutex profile
- Scheduler/pathological latency behavior -> runtime trace (flight recorder for rare events)
- Growing goroutine count / suspected stuck workers ->
goroutineleak profile, then the full goroutine profile
- Shipped binary that is already profile-tuned and needs final runtime/build tuning ->
compiler-and-runtime-tuning.md
Safety note: exposing pprof
net/http/pprof endpoints can leak sensitive runtime data. Prefer:
- bind to
localhost
- protect with auth / firewall
- enable only in dev / controlled environments
Resources
Load these references on demand:
references/profiling.md — pprof + trace + goroutineleak + flight recorder
references/benchmarks.md — stable benchmarks, -benchmem, benchstat, hygiene
references/allocations-gc.md — allocation patterns, Green Tea GC, slice retention, sync.Pool
references/contention.md — mutex/block profiles, contention patterns, backpressure
references/compiler-and-runtime-tuning.md — load when code-level fixes have landed and you need PGO, GOGC/GOMEMLIMIT, GOMAXPROCS/cgroup, GC/cgo/thread knobs, or shipped-binary build flags
1---2name: golang-performance3description: Go performance workflow: benchmark and profile (pprof/trace), identify hotspots, reduce allocations/GC and contention, and verify improvements with repeatable measurement. Use only after you have evidence the Go code is the bottleneck.4license: MIT5---67# Go Performance89This skill is about **measurement-first optimization** in Go.1011## When to activate1213Use this skill when you need to:1415- Confirm a performance regression (latency/throughput/CPU/memory)16- Identify hot paths with pprof (CPU / heap / mutex / block)17- Reduce allocations and GC pressure in a measured hotspot18- Fix contention (mutex, scheduler, channel backpressure)19- Validate improvements with benchmarks and repeatable runs2021If you need general idioms and patterns (not measurement), use `golang-patterns`.2223---2425## Rules of engagement2627- **Profile before optimizing.** A fast guess beats a slow change.28- **Change one thing at a time.** Measure after each change.29- **Keep a baseline.** Every claim should have “before vs after”.30- **Don’t optimize the cold path.** Make the hot path boring.3132---3334## Outcome expectations3536- Performance claims are backed by reproducible before/after measurements.37- Profile type selection matches the observed symptom.38- Optimizations are incremental, attributable, and regression-resistant.3940---4142## Workflow43441. **Make it measurable**45 - Add a benchmark (or a reproducible load test) for the suspected hotspot.46 - Run multiple iterations; record mean + variance.47482. **Capture evidence**49 - CPU profile for time50 - Heap/allocs profile for memory51 - Mutex/block profiles for contention52 - Trace when the scheduler / GC behavior matters53543. **Analyze before changing code**55 - Identify top offenders (`top`, `top -cum`)56 - Inspect annotated source (`list`)57 - Confirm whether you are bound by CPU, allocations, syscalls, or contention58594. **Apply targeted fixes**60 - Allocation and GC: reduce allocations, reuse buffers, avoid retaining large backing arrays61 - Data layout: improve locality, avoid interface boxing in hot loops62 - Concurrency: reduce contention, bound goroutines, add backpressure63645. **Verify and document**65 - Re-run the benchmark/profile66 - Ensure correctness isn’t traded away67 - Record the change and its measured impact6869---7071## Symptom to first profile mapping7273- High CPU -> CPU profile74- Memory growth -> heap profile (compare snapshots)75- High allocation churn / GC pressure -> allocs profile76- Latency spikes without CPU spike -> block profile77- Lock contention suspicion -> mutex profile78- Scheduler/pathological latency behavior -> runtime trace (flight recorder for rare events)79- Growing goroutine count / suspected stuck workers -> `goroutineleak` profile, then the full goroutine profile80- Shipped binary that is already profile-tuned and needs final runtime/build tuning -> `compiler-and-runtime-tuning.md`8182---8384## Safety note: exposing pprof8586`net/http/pprof` endpoints can leak sensitive runtime data. Prefer:87- bind to `localhost`88- protect with auth / firewall89- enable only in dev / controlled environments9091---9293## Resources9495Load these references on demand:9697- `references/profiling.md` — pprof + trace + `goroutineleak` + flight recorder98- `references/benchmarks.md` — stable benchmarks, -benchmem, benchstat, hygiene99- `references/allocations-gc.md` — allocation patterns, Green Tea GC, slice retention, sync.Pool100- `references/contention.md` — mutex/block profiles, contention patterns, backpressure101- `references/compiler-and-runtime-tuning.md` — load when code-level fixes have landed and you need PGO, GOGC/GOMEMLIMIT, GOMAXPROCS/cgroup, GC/cgo/thread knobs, or shipped-binary build flags