Dynamic code timing

rocky edited this page Aug 24, 2010 · 2 revisions

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.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.