golang-performance

Profile first with pprof or fgprof before changing code, since intuition about bottlenecks is wrong most of the time. Then write an atomic benchmark, measure a baseline with -benchmem -count=6, apply one optimization at a time, and confirm with benchstat.

Reuse slice backing arrays with append(s[:0], ...), preallocate maps with size hints, use sync.Pool for short-lived objects, and avoid interface boxing with generics or typed parameters. Check escape analysis with go build -gcflags="-m".

Use fgprof, which captures both on-CPU and off-CPU wait time. Low CPU with high latency means goroutines are blocked on I/O such as network or database calls, which standard CPU profiling does not capture.

No. Go maps never release bucket memory when entries are deleted, so a map that held millions of keys retains its peak allocation. Replace the map with a fresh make() to let the old buckets be garbage collected.

Use sync.Pool for frequently allocated, short-lived objects in hot paths like HTTP handlers. Reset state before Put, return copies rather than pooled buffers, and avoid pooling objects larger than about 32KB.

Field ordering causes padding bytes for alignment. Reorder fields from largest to smallest (int64 first, bools last) and run the fieldalignment tool to detect wasted space automatically.