The Mechanics of Ruby
summary
Examines MRI internals and makes concrete claims: MRI’s C heritage explains type checks and the global lock, JRuby and Rubinius aim for faster VMs, and many Ruby apps spend surprising time in GC and string buffering. Uses perftools.rb and DTrace to profile a laughable database and a Rails app, finds millions of malloc calls vs ~35k when allocations drop, removes a stray dev dependency and reduced render time from ~1s to ~0.5s, proving measurements and small fixes work.
AI-written summary · about
chapters (19)
- 0:00Start
- 3:11What if we were scientists?
- 3:45What if we were prankster scientists?
- 6:18Now, we can write some C codes. #include "ruby.h"
- 10:37Conspicuously missing
- 12:42An procedural code
- 12:58An object-oriented
- 13:25An DSL-oriented code
- 13:40So what's this?
- 18:34perftools.rb, a sampling profiler
- 20:23All the method calls, a LOL, database
- 20:59rack-perftools_profiler
- 21:39What your Rails app probably looks like
- 22:34A wild, coincidental bottleneck appears
- 33:13Read things.
- 36:31Take it apart with dtrace
- 38:35Hey, I wonder what my Ruby program really does?
- 39:29How a bytecode is
- 40:02MRI isn't fast because of all the other stuff
related talks
55mComplex Ruby concepts dummified
44mWhy JRuby?
27mDigesting MRI by Studying Alternative Ruby Implementations
47mWhy JRuby Works
33mConcurrency for !Dummies (Who Don't Get It (...Yet))
39mJRuby: Insights from Six Years in Production
37mWhat’s happening in your Rails app? Introduction to Introspection features of Ruby
24mRuby Performance Secrets and How to Uncover Them