Cutting down on the DEBUG bloat...

[Paul Lindner <li...@inuus.com>]

Hi,

As part of my ongoing effort to streamline my mod_perl apps, I've come
to discover the joy of constant subroutines and perl's ability to
inline or eliminate code at compile time.  I have a solution that
works, but would be interested in seeing if others had better
syntactic sugar..  Anyway:

We have a module CP::Util, with this begin block:

  BEGIN {
    $ENV{CP_DEBUG} ||= 0;
    if ($ENV{CP_DEBUG} == 1) {
      *{CP::Util::DBG} = sub () {1;};
    } else {
      *{CP::Util::DBG} = sub () {0;};
    }
  }
  @EXPORT_OK = qw(DBG);


Then, in another module I do:

  use CP::Util qw(DBG);

  DBG && debug('whoa there boy');


The end result is, when CP_DEBUG=1, the code is in there.  When
CP_DEBUG=0, the code is trimmed out at compile time (because DBG is a
constant subroutine, see perldoc perlsub for more info)

This is a real win compared to our old way of using a subroutine
called debug that did a no-op.  Consider:

   debug 'whoa there' . $foo . join(keys(%bar));

The args to debug are still computed, passed on the stack, etc..

Now, my question is: Is there some trick I could use to retain the simple syntax:

  debug "foo bar";


In any case I hope the above exercise opens up everyone's eyes.  Just
goes to show that your debug statements might actually be slowing your
mod_perl application.

Cheers.

-- 
Paul Lindner
lindner@inuus.com

Re: Cutting down on the DEBUG bloat...

[Perrin Harkins <pe...@primenet.com>]

> As part of my ongoing effort to streamline my mod_perl apps, I've come
> to discover the joy of constant subroutines and perl's ability to
> inline or eliminate code at compile time.  I have a solution that
> works, but would be interested in seeing if others had better
> syntactic sugar..

You could use Filter::CPP with #ifdefs for this.

#ifdef DEBUGGING
print STDERR $some_thing;
#endif

- Perrin

Re: Cutting down on the DEBUG bloat...

[barries <ba...@slaysys.com>]

On Thu, May 10, 2001 at 03:28:16PM -0700, Doug MacEachern wrote:
>
> http://perl.apache.org/~dougm/condsub-0.01.tar.gz
> 
> see test.pl for the examples.
> i'm open to names/interface changes

I've had good luck (on non performance critical code) doing something
like (from memory):

   use Regexp::Shellish "compile_shellish" ;

   my $debug_pat = join "|", map compile_shellish( $_ ), @$opt_debug ;

   sub debugging { caller =~ /$debug_pat/ }

   ...code passes...

   debug "Egad! say it ain't so!" if debugging ;

(debug() emulates Data::Dumper--which is too limited w.r.t. Regexps and
CODE refs in some perls--to dump refs, prints "<undef>" for undefined
vals, etc.).

This has let me selectively enable debugging at the command line by
defining -d to take strings like:

    foo -d Foo::Bar
    foo -d Foo::*
    foo -d Foo::* -d Bar::*
    foo -d          ## Same as -d "*"

which lets me debug a class, package, group of same, or the entire app.

Since __PACKAGE__ is known at compile time, perhaps something like this
be "front-ended" to your optimization without noticable performance
penalty.  It's really nice (IMESHO) to be able to focus debugging on a
subsystem like this on larger apps, or apps with a pluggable
architecture.

The main pain is for OO code where Blah inherits from Foo, you can't
cheaply write debugging() so that it's sensitive to inheritence.  Since
the app is not performance sensitive (it forks around a *lot*) I
actually did something like:

   sub debugging {
      grep /$debug_pat/, ((caller 0)[3] || "main::"), @_ ;
   }

which allowed me to do things like

    debug "Um, doing something" if debugging ;
    debug "Um, doing something" if debugging $self ;
    debug "Um, doing something" if debugging "output" ;

in methods.  I ended up caching a few things and instrumenting it a
little so I could issue warnings in an END sub if any of the -d args
weren't checked against actual code, meaning that you probably mispelled
a -d value.  I've been meaning to clean that up and put it in a module
for some time.  I'll get it out sooner now :-).

Anyway, just an API that I've found useful.
          
- Barrie

Re: Cutting down on the DEBUG bloat...

[barries <ba...@slaysys.com>]

On Thu, May 10, 2001 at 03:28:16PM -0700, Doug MacEachern wrote:
> On Tue, 10 Apr 2001, Paul Lindner wrote:
> > 
> >   DBG && debug('whoa there boy');

FWIW, you may find the opcode-identical

   debug 'whoa there boy' if DBG ;

more readable.  Don't go to values other than 0 or 1 (not even "0" or
"1") for DBG for either or you'll get Useless use of a constant in void
context warnings...

> http://perl.apache.org/~dougm/condsub-0.01.tar.gz

Very cool.

- Barrie

Re: Cutting down on the DEBUG bloat...

[Doug MacEachern <do...@covalent.net>]

On Tue, 10 Apr 2001, Paul Lindner wrote:

> Hi,
> 
> As part of my ongoing effort to streamline my mod_perl apps, I've come
> to discover the joy of constant subroutines and perl's ability to
> inline or eliminate code at compile time.  I have a solution that
> works, but would be interested in seeing if others had better
> syntactic sugar..  Anyway:
> 
> We have a module CP::Util, with this begin block:
> 
>   BEGIN {
>     $ENV{CP_DEBUG} ||= 0;
>     if ($ENV{CP_DEBUG} == 1) {
>       *{CP::Util::DBG} = sub () {1;};
>     } else {
>       *{CP::Util::DBG} = sub () {0;};
>     }
>   }
>   @EXPORT_OK = qw(DBG);
> 
> 
> Then, in another module I do:
> 
>   use CP::Util qw(DBG);
> 
>   DBG && debug('whoa there boy');
> 
> 
> The end result is, when CP_DEBUG=1, the code is in there.  When
> CP_DEBUG=0, the code is trimmed out at compile time (because DBG is a
> constant subroutine, see perldoc perlsub for more info)
> 
> This is a real win compared to our old way of using a subroutine
> called debug that did a no-op.  Consider:
> 
>    debug 'whoa there' . $foo . join(keys(%bar));
> 
> The args to debug are still computed, passed on the stack, etc..
> 
> Now, my question is: Is there some trick I could use to retain the simple syntax:
> 
>   debug "foo bar";

it is possible, and has been on the "optimizations" slide for the 2.0
talks i've been giving.  one idea i had in mind was:

$r->log->debug(...);

would be nulled out unless LogLevel is configured to debug.

i have fiddled with it, you can try this:
http://perl.apache.org/~dougm/condsub-0.01.tar.gz

see test.pl for the examples.
i'm open to names/interface changes, the module is just a
proof-of-concept.

Re: Cutting down on the DEBUG bloat...

["Jeffrey W. Baker" <jw...@acm.org>]

On Tue, 10 Apr 2001, Paul Lindner wrote:

> Now, my question is: Is there some trick I could use to retain the
> simple syntax:
>
>   debug "foo bar";

I always liked using a preprocessor to turn debug code on or off.  ePerl
is OK, and Perl can of course be its own preprocessor.

-jwb