Comment 1:

Slightly less awful on linux/arm
localhost(~/go/src/pkg/fmt) % ~/go/misc/benchcmp {old,new}.txt
benchmark                      old ns/op    new ns/op    delta
BenchmarkSprintfEmpty                751          889  +18.38%
BenchmarkSprintfString              1702         1999  +17.45%
BenchmarkSprintfInt                 1405         1701  +21.07%
BenchmarkSprintfIntInt              1981         2234  +12.77%
BenchmarkSprintfPrefixedInt         1978         2237  +13.09%
BenchmarkSprintfFloat               4079         4397   +7.80%
BenchmarkManyArgs                   7054         7197   +2.03%
BenchmarkScanInts                5443710      5773931   +6.07%
BenchmarkScanRecursiveInt        7618105      8175157   +7.31%

Comment 2:

Actually I'm pleased it's so close. But yeah. It used to be a channel, but we made this
change for a reason.

Comment 3:

A buffered channel is a slice, a mutex, and extra stuff to make select work. It would be
embarrassing for the slice and mutex if that combination were somehow faster than a
slice+mutex alone. So "buffered channels are slower than a slice and a mutex" is working
as intended.
There is a possibly bigger difference in your CL, though. The slice+mutex in fmt is a
stack, and you are replacing it with a queue. If there are five entries in the cache,
the stack will just keep reusing one of them, while the queue will cycle through all
five. You'll touch less memory using the stack, which is part of why it's there.

Status changed to WorkingAsIntended.

Comment 4:

Np. Thanks for the explanation.

Comment 5:

I am just making a mental picture of "embarrassed slice and mutex combination" ... No,
no such luck. :-)
Alex