Go code refactoring : the 23x performance hunt

Val Deleplace
May 29, 2018 · 9 min read

$ go test -bench=.
μs per execution (smaller is better)
Climbing mount Simplicity, and then descending it
$ go test -bench=. -cpuprofile cpu.prof
$ go tool pprof -svg cpu.prof > cpu.svg
A pretty big CPU usage graph (click for SVG)
$ go test -bench=. -trace trace.out
$ go tool trace trace.out
A rainbow trace : lots of tiny tasks (click to open, in Chrome only)
A 3ms window (click to open, in Chrome only)
$ go test -race
PASS
μs per execution (smaller is better)
μs per execution (smaller is better)
With a single goroutine, only 1 CPU core is working at any given time.
Spotting the bottleneck
patternSubfield = "-.[^-]*"
μs per execution (smaller is better)
This function calls intrigue me: can we do better?
μs per execution (smaller is better)

μs per Message (smaller is better, purple is concurrent)
μs per Message (smaller is better, purple is concurrent)
μs per Message (smaller is better, purple is concurrent)

Lexical Scanning in Go — Rob Pike
μs per Message (smaller is better, purple is concurrent)

Thanks to Alexis MP

Val Deleplace

Written by

Engineer on cloudy things @Google. Opinions my own. Twitter @val_deleplace

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade