So You Wanna Go Fast?
summary
Concrete, measurable takeaways: Go code shows order-of-magnitude differences when you change representations — sorting 100M items via interfaces can take about 100s vs 25s for structs; avoiding one allocation boosts NATS throughput by 2 million messages/second; empty interface conversions trigger allocations and GC overhead; channels are effectively a locked ring buffer and mutexes often win on tight paths. Uses pprof, benchmarking, HDR histogram and sync.Pool insights (the sync.Pool per-CPU trick). Built lock-free concurrent tree and a big-reader-lock that scale well and required fixing an empty interface allocations bug.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 0:35The Better Title
- 1:55Who am I
- 2:44Why this talk matters
- 5:01Dont blindly apply optimizations
- 8:12Channels
- 10:38Overhead
- 11:32Interfaces
- 17:35Benchmark
- 22:48SinkPool
- 28:25Go Race Detector
- 29:50Unsafe
- 30:33Mechanical Sympathy
- 33:56Big Reader Lock
- 36:03Conclusion
related talks
51mObscure Go Optimisations
14mOptimizing Go code without a blindfold
25mTackling Contention : The Monster in sync.Locker
14mMemory Optimization through Structure Packaging
20mOptimizing Go code without a blindfold
40mTwo Go programs, three different profiling techniques, all in 40 minutes
30mHigh Performance Systems in Go
01h 27mFlash Talks