
The 30% is 46%, and it stops dead at 80 bytes
Go 1.27's size-specialised allocation is worth up to 46% on the pointer-containing path, not the 30% announced — and from 96 bytes up it is worth nothing.
Long-form notes on the Go runtime, concurrency, performance and the systems underneath.
Page 1 of 2

Go 1.27's size-specialised allocation is worth up to 46% on the pointer-containing path, not the 30% announced — and from 96 bytes up it is worth nothing.

A gctrace line carries eleven numbers. Two are stop-the-world, one has a third of the GC subtracted out of it, and the biggest one is not a pause at all.

One heap shape lost 63% of its collector CPU and gained 14% throughput. Another gained 39% collector CPU and lost nothing. Same flag, same binary pair, same machine.

GOGC=100 with a 256 MiB limit produced exactly what GOGC=off produced: same collections, same CPU share, same throughput. The tighter rule binds, the other goes quiet.

A static route through net/http's mux costs 85.6 ns and nothing on the heap. A path that matches no pattern costs 2125.5 ns and 62 allocations.

One goroutine: 2.5 ns for the mutex, 172.6 ns for the channel. Sixteen goroutines with real work: the channel wins by less than the harness's own error.

Reaching a 1 MiB stack copied it nine times. The copying cost 136µs of CPU that -benchmem reports as 144 bytes, because stack memory is not heap memory.

Two sub-benchmarks calling the same function with the same argument came back 1.10% apart at p=0.000. What a benchmark measures is not only your code.

GOMAXPROCS=1 with 200 goroutines blocked in read(2) produced 202 OS threads. Measured on go1.27.0, alongside the container case Go 1.25 changed.

A pool holding 100 objects lost none across one collection and all 100 across two. Here is the victim cache, and what it costs at 122,000 ops per millisecond.