Optimizing Partial Backtraces in Ruby 3
summary
Backtrace generation in Ruby 3 changes from scanning outward to scanning inward, producing partial backtraces far faster by avoiding work on irrelevant control frames — an initial patch speeds some cases to about 6× faster for deep (~400 frame) stacks but introduces a missed frames bug fixed in 3.0.1. A new algorithm that scans from the most recent frame is simpler, about twice as fast than the optimized inward approach, and lands for broader use.
AI-written summary · about
chapters (17)
- 0:00Backtrace optimization intro
- 2:08What backtraces are
- 4:52Ruby VM control frames
- 5:33Ruby 2.7 backtraces
- 9:42Partial backtrace slowdown
- 10:02Optimizing in Ruby 3
- 12:06First bug in algorithm
- 13:30Second regression
- 16:57Optimization limits
- 17:19New backtrace design
- 20:47Advantages of new design
- 21:29Ruby 3.1 bugs
- 22:33Backporting Ruby 3.0 fixes
- 25:43Ruby 3.0.3 fixes
- 26:04Optimization lessons
- 27:10Closing and book promo
- 27:38Q&A on backtraces
related talks
28mTracing your way through Ruby
46mRuby3: What's Missing?
37mWhat’s happening in your Rails app? Introduction to Introspection features of Ruby
36mDebugging Ruby
34mHow to optimize Ruby internal.
38mDispelling the dark magic: Inside a Ruby debugger
41mSpeed up Rails, Speed up Your Code
29mChasing Real-Time Observability for CRuby