Performance Improvement of Ruby 2.7 JIT in Real World
summary
Ruby 2.6 JIT speeds microbenchmarks like Optcarrot but slows real Rails workloads; Ruby 2.7 targets Rails-specific fixes. Experiments show linking many .o into one .so and disabling speculative inline-cache optimizations reduce overhead; profile‑guided optimization brings little gain. Measured hotspots are 12M calls 3M JIT 2M cancels, VM/method-call overhead ~40%, and object allocation ~9%. Proof‑of‑concept stack allocation and Ruby‑redefined core methods cut allocation and call overheads, but scaffold benchmarks remain not yet faster than VM.
AI-written summary · about
chapters (23)
- 0:00Performance Improvement of Ruby 2.7 JIT in Real World
- 1:17What's "MJIT"?
- 4:27Ruby 2.6 JIT stability
- 5:14Ruby 3x3 benchmark: 1. Optcarrot
- 6:42What's "real world"?
- 7:00Ruby 3x3 benchmark: 2. Discourse
- 9:31Discourse: Speed
- 10:39Why JIT is not fast yet on Rails?
- 11:18New Ruby benchmark: Railsbench
- 11:49Railsbench: Speed
- 12:23Railsbench: Memory
- 13:52Ruby 2.7 JIT Performance Challenges
- 16:29Approach 1: Profile-guided Optimization
- 17:55Can we avoid making things slow?
- 18:25Approach 2: Optimization Prediction
- 22:52JIT calls may be cancelled frequently
- 26:30Deoptimized Recompilation
- 28:10Method call is slow
- 32:10Solution 4: Frame-omitted Method Inlining
- 33:28Object allocation is slow
- 34:09Stack-based Object Allocation
- 37:22More Ruby code in core
- 38:18Conclusion
