The author gives an example where running a benchmark tool and identifying the output for the "fizzbuzz" benchmark is ./runbenchmarks | grep '^fizzbuzz' w

The author gives an example where running a benchmark tool and identifying the output for the "fizzbuzz" benchmark is ./runbenchmarks | grep '^fizzbuzz' with his preferred style of output and ./runbenchmarks | awk '/^Benchmark:/ { bench = $2} bench=="fizzbuzz"' with another. That's fair enough, but what he doesn't mention is that running the tool and interpreting its output is ./runbenchmarks with the second style of output and ./runbenchmarks benchmarks --help # damn, it just lists the command-line options vim benchmarks.c # look through source code to find what the random numbers after the program name mean with the first. The culprit here is the fact that his preferred style not only puts each benchmark's output on one line but also omits the "Time:" and "Alloc:" and "ns/op" and "bytes/op" which make the numbers generated actually mean something to a human being. I think the correct answer here may be to have a command-line flag selecting between two kinds of output, one intended for humans to read and one intended for programs to parse. Or maybe for the output to look like fizzbuzz: 10 ns/op, 40 bytes/op or fizzbuzz 10 ns/op 40 bytes/op either of which is pretty easy to parse for both humans and computers. Or even fizzbuzz time 10 ns/op fizzbuzz alloc 40 ns/op which lets you see all the results for the fizzbuzz benchmark with the same grep as above, and all benchmarks' time results with another almost-as-simple grep, at the cost of a little redundancy in the output. Higher-level message: when you have two competing requirements (make things readable for humans, and make things parseable for programs), before just picking one as The One That Matters consider whether maybe there's a way to get both.