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...

[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...

[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