ext/profile, or How to Make Profilers Tell the Truth
summary
Profilers often miss hot work because RB_profile_frames only sees real frames, so specialized instructions and inlined methods disappear; a working hack synthesize virtual frames by decoding the instruction at the PC and correctly surfaces integer plus and regex work. Heavy stack decoding moves out of the signal handler by deferring stack walking to postponed jobs, allowing caching and safe allocations. Proposal: embed an ext profiler in CRuby that emits per-sample stack events so existing tools aggregate CPU- and wall-time-correct profiles and handle ractors and thread migration.
AI-written summary · about
chapters (8)
- 0:00Introduction to profiling
- 2:52Status quo of Ruby profilers
- 7:50Blind spots in stack walking
- 15:14Invisible inlined methods
- 16:41Ruby’s evolving landscape
- 20:31Proposal for Xprofiler
- 27:21Comparing profiler models
- 28:04Conclusion and Q&A
related talks
26mHow a Ruby profiler works: Stackprof under a microscope
31mProfiling Formats and Why You Should Care
36mDeveloping Continuous eBPF Profiler to look Beneath the Kernel to Beyond the Clouds
24mDIY::Thread.profile -- Light-Weight Profiling in Pure Ruby
37mThe Future of Ruby Performance Tooling
51mProduction Profiling: What, Why and How
38mAdvanced BPF profiling techniques: how to escape the curse of NMI and fetch ELF...
33mDecent into Darkness: Understanding Your System's Binary Interface...