perl -d: faster and less scary than you think

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/fib.pl";
+ print fib(28)'
317811

real    0m0.949s
user    0m0.941s
sys    0m0.006s
$ time perl -le 'do "/tmp/fib.pl"; print fib(28)'
317811

real    0m0.924s
user    0m0.918s
sys    0m0.005s
$ time perl -le 'BEGIN { sub DB::DB {}; $^P=0xfff }; do "/tmp/fib.pl";
+ 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/fib.pl"; print fib(28)'
317811

real    0m1.557s
user    0m1.548s
sys    0m0.006s
[download]

Comment on perl -d: faster and less scary than you think Select or Download Code

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
++educated_foo, 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. s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/	[reply]
Re^2: perl -d: faster and less scary than you think by doom (Deacon) on Jun 04, 2007 at 19:01 UTC
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).	[reply]
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.)	[reply]
Re^2: perl -d: faster and less scary than you think by educated_foo (Vicar) on Jun 04, 2007 at 03:04 UTC
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.	[reply]
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.	[reply]


go ahead... be a heretic
	PerlMonks