Why Your Go Benchmarks Are Lying
summary
Claim: Go microbenchmarks often lie because compiler optimizations, scheduler noise and CI VM variability hide or remove the measured work. Practical fixes include running macrobenchmarks on bare metal, using benchstat and change‑point detection to validate distributions, disable SMT and DFS to cut variance (authors observe up to 10x differences), and verify inlining/dead‑code with GC flags and assembly. Tools built and shared include honestbench, benv and bench‑gate for PR gating; these systems run on dedicated hardware and successfully catch regressions before release.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:11Performance benchmarks matter
- 8:25Micro vs macrobenchmarks
- 15:15Local pitfalls and tricks
- 21:41Reliable macrobenchmarks
- 30:44Three benchmarking questions
- 41:31CI benchmarking
- 45:52Go’s benchmarking
- 49:07Tools and next steps
- 52:26Q&A
related talks
47mMisnomers About Microbenchmarks
38mYour benchmark may not guide a real application performance
39mMicro Benchmarks
01h 11m“Benchmarking C++ Code"
29mPractical guide to benchmarking your optimizations
47mUsing Benchmarks for Tracking Regressions and Improving UI performance
40mBenchmarketing fallacies: the 100 shades of truth
42mPerformance Matters