Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

perl -d: faster and less scary than you think

by educated_foo (Vicar)
on Jun 03, 2007 at 17:22 UTC ( #618979=perlmeditation: print w/replies, xml ) Need Help??

I had always assumed that perl's debugging hooks would only work if perl was run as perl -d, and would make your program horribly slow. It turns out that neither assumption is true. First, any code compiled while suitable $^P flags are set (see perldebguts), even when Perl is started without "-d", is debuggable. Second, when $DB::trace is 0 and minimal debugging flags are set, there seems to be no appreciable overhead. Specifically, with $^P = 0x303, which allows single-line stepping and gives nice caller information for evals and anonymous subs, debugging is essentially free.

To me, at least, this is seriously cool. I'm surprised this isn't more widely known or used.

Update: If you're wondering what prompted this, check out Sepia version 0.90 shortly. It only takes a couple hundred lines of ELisp + Perl to get a pretty decent GUD debugger in Emacs, and a minimal one would probably be less than 100. Once again, thank you Free Software!

Here are the benchmarks, with typical runtimes on my system:

sub fib { my $n = shift; if ($n < 2) { return $n; } else { return fib($n-1) + fib($n-2); } } __END__ $ time perl -le 'BEGIN { sub DB::DB {}; $^P=0x303 }; do "/tmp/"; + print fib(28)' 317811 real 0m0.949s user 0m0.941s sys 0m0.006s $ time perl -le 'do "/tmp/"; print fib(28)' 317811 real 0m0.924s user 0m0.918s sys 0m0.005s $ time perl -le 'BEGIN { sub DB::DB {}; $^P=0xfff }; do "/tmp/"; + print fib(28)' 317811 real 0m1.719s user 0m1.712s sys 0m0.006s $ time perl -le 'BEGIN { sub DB::DB {}; $^P=0x303; $DB::trace=1 }; do +"/tmp/"; print fib(28)' 317811 real 0m1.557s user 0m1.548s sys 0m0.006s

Replies are listed 'Best First'.
Re: perl -d: faster and less scary than you think
by liverpole (Monsignor) on Jun 04, 2007 at 03:03 UTC

    You make some good points, and I admit that my "list of things to learn more about" in Perl includes the debugger.  It's hard to find to find the time, however, because the "old tricks" in debugging get so ingrained, and Perl makes it so easy to debug without going to the debugger.

    But I appreciate the comments you make in your post, because they're a reminder that the Perl debugger is so versatile, and your argument about the lack of a significant time penalty is all the more reason to consider moving this "todo" higher on my mental list.

      My standard rap about the perl debugger is that it only takes around a half-an-hour of playing around to learn to use it, but you need to do this some time when you're not worrying about a bug.

      Also, if you start out reading one of the standard references it's easy to get scared away by the sheer quantity of commands (there's around fifty, not counting all of the various options).

      I recommend just starting with these:

      • s - single step
      • n - steps carefully to avoid falling into a sub
      • c - continue processing until a break of some sort
      • r - continue running until you do a return from the current sub
      • v - view some code around the current line
      • b - sets a break point (uses line number or sub name)
      • x - displays value of variables (including arrays & hashes)
      • w - sets a watch expression
      • T - displays a stack back trace
      • L - list all the breaks and watches
      • B * - delete all breakpoints
      • W * - delete all watch expressions
      • R - restart

      (I wrote a debugger tutorial once, but it's way out-of-date. There's a standard one now: perldebtut).

Re: perl -d: faster and less scary than you think
by doom (Deacon) on Jun 04, 2007 at 02:43 UTC
    Myself I use "perl -d" debugging all the time, and while it's probably slower, it's fast enough to help me figure out what's going on pretty quickly.

    I also frequenly run the perl debugger using the emacs gud front-end, though I've only briefly looked at sepia (another thing for the todo list). It's pretty much a matter of feeding the right perl command into the emacs "compile" command.

    (I wrote an elisp package to help with that sort of thing: perlnow.el.)

      Sepia has come a long ways since your review. Myself, I've always found the Perl debugger more painful than print statements, and didn't discover gud's perl debugger function until I had become used to using Sepia and print. Besides, what I am aiming for with Sepia is not an improved debugger, but a Lisp-style development model for Perl, where you experiment at the prompt, and errors give you a prompt to play with.

      Anyways, the point of my post was that you might as well always run with some debugging enabled, since it costs nothing and lets you diagnose problems without having to come up with test cases to reproduce them.

Re: perl -d: faster and less scary than you think
by kwaping (Priest) on Jun 04, 2007 at 17:20 UTC
    For readers who are interested in learning more about the perl debugger, here are a couple of useful nodes that I keep in my Personal Nodelet:

    Using the Perl Debugger (-d)
    Neat Debugger tricks

    It's all fine and dandy until someone has to look at the code.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://618979]
Approved by BrowserUk
Front-paged by Old_Gray_Bear
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (8)
As of 2018-06-22 08:29 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (122 votes). Check out past polls.