Note: I take no credit for finding this. For an in-depth overview, check out Jemma Issroff’s IRB’s Built-in Measure post.
How do you know if a command you’re running in Ruby is slow? You can write a quick script using Ruby’s Benchmark module. This is a great way to compare thousands of iterations of a specific code path.
But what about the random commands you run in the
REPL? Ruby 3.0 introduced the
measure module, which can be set to output a recap of each command:
irb> measure :stackprof
irb> Post.all.length
Post Load (376.7ms) SELECT "posts".* FROM "posts"
==================================
Mode: cpu(1000)
Samples: 864 (3.25% miss rate)
GC: 93 (10.76%)
==================================
TOTAL (pct) SAMPLES (pct) FRAME
290 (33.6%) 289 (33.4%) SQLite3::Statement#step
136 (15.7%) 136 (15.7%) ActiveModel::AttributeSet#initialize
91 (10.5%) 91 (10.5%) (marking)
88 (10.2%) 88 (10.2%) ActiveRecord::Result#hash_rows
70 (8.1%) 70 (8.1%) Class#allocate
203 (23.5%) 67 (7.8%) ActiveModel::LazyAttributeSet#initialize
[snip]
=> 152941
This gives you a break down of where your code is spending its time. This intentionally-bad query spends quite a while in the SQLite3 module. While I have yet to use this in anger, I am glad to know it exists.