Re: Cutting down on the DEBUG bloat...
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 "" 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...
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...
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
Ah yes...
I remember it well.
CricInfo's home grown advert engine (mod_perl resident) was running like
the proverbial drain, and being its author, I was tasked to find out why.
A brief course through Devel::DProf later, we found the top of the
profiling tree in terms of time spent to be a sub() which basically went
sub debug
{
print @_ if $AdLib::DEBUG;
}
It was using over HALF the execution time.
--
Mike Whitaker| Work: +44 1733 766619 | Work: [EMAIL PROTECTED]
System Architect | Fax: +44 1733 348287 | Home: [EMAIL PROTECTED]
CricInfo Ltd | GSM: +44 7971 977375 | Web: http://www.cricket.org/
Re: Cutting down on the DEBUG bloat...
> 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...
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
