Go code refactoring : the 23x performance hunt

$ 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)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store