Dynamic code timing
Clone this wiki locally
A little while back I added this little debugger command to help me make a case for why breakpoint support has to be inside the Ruby interpreter rather than being largely interpreted inside a trace hook.
Inside the debugger if you issue:
set timer on
the debugger will tell you how long it took between debugger prompts. I quickly realized this would also help me track down other bottlenecks in the debugger.
But wait, there’s more!
Suppose you want to time sections of your code. Since breakpoints are handled by the interpreter (in the patched Ruby implementation), “set timer” can tell you just how long code you wrote takes to run. Just make sure you use breakpoints and the “continue” command.
I should give a fully worked out example.
One last geeky thing I find is cool. As with “set auto list,” “set display,” and “set auto irb,” “set timer” is implemented inside the debugger as a command-processor hook. Command-processor hooks are just ways to run some sort of Ruby code (in the form of a Proc) before or after the debugger command loop.