Source filters can be a solution. very little overhead. I wrote
Filter::Uncomment just for that.
On Friday 07 September 2007 03:58, John Siracusa wrote:
> On 9/6/07 4:14 PM, [EMAIL PROTECTED] wrote:
> > So why do CPAN modules eschew the use of these and invent their
> > own mechanisms that are almost guaranteed to be less powerful?
>
> I agree with all your listed reason, but I think you missed one: minimum
> overhead. Ideally, logging would disappear entirely from the code path
> when disabled. Perl being Perl, this is rarely possible, but that doesn't
> mean the other extreme--at least one method call per log line--is suddenly
> attractive. Here's a brief microbench showing the range of overhead for
> disabled logging:
>
> package A;
> sub a { 0 }
> sub c() { 0 }
> our $Debug = 0;
>
> package main;
> use Benchmark qw(cmpthese);
> my $o = bless {}, 'A';
> cmpthese(10000000, {
> method => sub { $o->a && $o->a },
> sub => sub { A::a() && $o->a },
> var => sub { $A::Debug && $o->a },
> #const => sub { A::c() && $o->a },
> });
>
> Rate method sub var
> method 1176471/s -- -13% -92%
> sub 1349528/s 15% -- -91%
> var 15625000/s 1228% 1058% --
>
> As you can see, though sub vs. method is a small difference for the best
> case (sub and method both returning a constant 0), the $Debug && ... case
> beats it by enough to be significant.
>
> (I commented out the constant case because it's best case, as close as Perl
> can come to actual code removal (depending on where/when the constant sub
> is defined).)
>
> So I guess what I'm saying is that the final thing that would stop me from
> using Log::Any "everywhere" (meaning also in performance-critical code) is
> the overhead for the common (production) case of logging being entirely
> disabled. How about providing all three methods of checking as part of the
> API?
>
> $log->debug(...) if $log->is_debug(); # method
> $log->debug(...) if Log::Any::is_debug(); # sub
> $log->debug(...) if $Log::Any::Is_Debug; # var
>
> Yes, a backend (maybe the default/built-in backend, in fact) could chose to
> implement the sub by calling a method and the var with a tie, negating a
> lot of the performance benefit, but at least the door is open for a simple
> backend to implement the var and sub directly, yielding the full benefit.
>
> -John
