Inlining: bright victories and hidden defeats
summary
Explains how Go’s function inlining actually works: compiler uses a budget = 80 cost model (counts base ops and call cost), inlining exists since Go 1.10, mid-stack inlining lands in 1.12 and more fixes target 1.14. Shows concrete tradeoffs: call overhead ~1–2 ns vs add ~0.1 ns, typical binary size growth 2–3% (experiments 7–50%), a hot/cold split yields ~6x speedup in a microbenchmark and moving heap allocations into inlined code eliminates them giving roughly 3x speed improvements.
AI-written summary · about
chapters (14)
- 0:00Inlining introduction
- 2:08What is inlining
- 5:38Inlining pros and cons
- 7:23Inlining in Go
- 10:14Function cost model
- 13:06Infinite loop example
- 16:44Cooperative multitasking issues
- 17:46Non-tail call inlining
- 21:19Inlining in practice
- 23:54Memory optimization and escape analysis
- 28:07Where optimization applies
- 30:15Future of compiler optimization
- 32:47JSON parsing optimization
- 34:57Q&A
related talks
24mFunction Inlining
06mProfile-Guided Optimization in the Go Compiler
01h 04m“Understanding Optimizers: Helping the Compiler Help You”
34mWhat happens to your code when you don't look?
26mHot Call-Chain Inlining for the Glasgow Haskell Compiler
17mInlined Code Generation for Smalltalk
48mOptimizing Performance using a VM and Go Plugins
34mGo Inline Assembler: Dream or Reality