← All benchmarksGo
Go sync.Pool vs allocating a new buffer: 21 ns vs 624 ns, 0 allocations
How much faster is sync.Pool than allocating a new bytes.Buffer each time in Go?
In a micro-benchmark, reusing buffers from sync.Pool took 21 ns/op with 0 allocations, versus 624 ns/op and 4,096 B/op for allocating a fresh buffer each time (about 29x faster).
Results
| new bytes.Buffer each time | 624 ns/op, 4,096 B/op, 1 alloc/op |
|---|---|
| sync.Pool | 21 ns/op, 0 B/op, 0 allocs/op |
How it was measured
2,000,000 iterations, each writes a short string and resets the buffer.
buf := bufPool.Get().(*bytes.Buffer)
work(buf)
bufPool.Put(buf)Why
sync.Pool caches objects between garbage collections so hot paths stop allocating.
When this does not apply
Pools can be emptied by the GC, objects must be reset before reuse, and the gain only matters on hot paths.
Environment
MacBook Air (Apple silicon, 8 cores), macOS, Go 1.22. Measured 2026-10-12.
Source: shorts/demo-ticket/w3/pool/pool_test.go in my content-engine repository. Treat any single run as a direction; re-run it on your hardware.
Related
By Josué Barros, senior software engineer (full-stack, data and AI).