JITs are Nice, but Why Aren’t We Using Them?
summary
Companies running thousands of Ruby projects find JITs deliver big peak wins but fail operational constraints: Truffle Ruby and YJIT hit 100% speedups in some cases yet impose longer warmup, higher memory and slower CI/test times; reimplementations (via Truffle or RPython) give a JIT for free but cost startup time and compatibility with native extensions; small steady wins (1–9%) matter at scale; recommendation is to invest in reducing warmup/memory and better control over generated code rather than chasing peak throughput alone.
AI-written summary · about
chapters (26)
- 0:00Introduction
- 0:25Why JIT compilers matter
- 1:09Shopify’s tech stack
- 2:54Consistent vs peak performance
- 4:20Developer time limits VM
- 6:46Shopify’s YJIT and TruffleRuby
- 7:49Ruby team’s dual runtime
- 9:13Dynamic languages’ history
- 11:00Ruby’s slow JIT adoption
- 11:41Cloud impact on performance
- 13:26Dynamic languages’ modern challenges
- 14:51New language success basics
- 15:11Why most lack JIT adoption
- 16:15Compatibility barriers
- 17:19Tooling gaps in Ruby/Python
- 17:39JIT success stories
- 18:21Cost of language-specific JITs
- 19:24JIT maintenance challenges
- 20:07Bytecode as JIT strategy
- 21:12Metacompilation advantages
- 22:36Why metacompilation rare
- 23:17Metacompilation non-peak costs
- 23:59Future of dynamic languages
- 25:24Dynamic languages’ midlife crisis
- 26:26JIT future: maintenance vs warmup
- 27:08Q&A