smile4me has asked for the wisdom of the Perl Monks concerning the following question:

So I use a $ENV{DEBUG_LEVEL} flag to turn on/off debugging in my project similar to this: 
#!/usr/bin/env perl
use constant DEBUG => $ENV{DEBUG_LEVEL};

sub debug {
    my $level = shift;
    return if ($level > DEBUG);
    print STDERR "($level/" . DEBUG . ") @_\n";
}


sub helpful {
    my $int = shift;
    debug(1, "called with: ", $int);
    ## do stuff here ...
    my $val = $int * $int;
    debug(3, "output: ", $val);
    print "$int becomes: $val \n";
}

for ( 1..5 ) {
  helpful( $_ );
}

[download]

After a while, the debug() statements become sprinkled all over the place. For me, it is helpful. But I am wondering if there is a cost to all these calls.

I tried testing this theory with:

DEBUG_LEVEL=3 perl -MO=Concise ./debug_onoff.pl

DEBUG_LEVEL=2 perl -MO=Concise ./debug_onoff.pl

DEBUG_LEVEL=0 perl -MO=Concise ./debug_onoff.pl

but the output is the same. See for related topic.

So the questions is:

  1. does the perl compiler optimize away the debug's when the ENV{DEBUG_LEVEL} is 0?
  2. is there a cost to leaving the debug()'s inline?
  3. should I remove them to improve performance overall?
  4. is there a better way to accomplish the goal of simple on/off for debugging one's code?

Thanks for your insight.

Replies are listed 'Best First'.
Re: perl compiler optimizer curiosity
by Athanasius (Archbishop) on Mar 12, 2022 at 04:23 UTC

    Hello smile4me,

    1. does the perl compiler optimize away the debug's when the ENV{DEBUG_LEVEL} is 0?

    No.

    2. is there a cost to leaving the debug()'s inline?
    3. should I remove them to improve performance overall?

    Yes, there is a cost, but it’s probably negligible. If performance becomes a problem, you should first profile the code using a module such as Devel::NYTProf to find the bottlenecks. Unless your debug statements are placed inside heavy-duty loops, it’s unlikely they will degrade performance significantly.

    4. is there a better way to accomplish the goal of simple on/off for debugging one's code?

    If you want the compiler to eliminate debugging code when debugging is not required, you need to code like this:

    use constant DEBUG => $ENV{DEBUG_LEVEL} // 0;        # Handle undef gr
+acefully

...

sub helpful {
    my $int = shift;
    debug(1, "called with: ", $int) if DEBUG > 0;    # <-- Add this
    ## do stuff here ...
    my $val = $int * $int;
    debug(3, "output: ", $val)      if DEBUG > 0;    # <-- Add this
    print "$int becomes: $val \n";
}

...

    [download]

    You can check with perl -MO=Deparse that when DEBUG == 0, the debug statements are removed by the compiler.

    Hope that helps,

    Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

[reply]
[d/l]
[select]
Re: perl compiler optimizer curiosity (Troubleshooting and Logging/Debugging References)
by eyepopslikeamosquito (Archbishop) on Mar 12, 2022 at 06:33 UTC
[reply]
[d/l]

      Seconding these recommendations. Log4perl overhead will be similar to your solution in the disabled case (a sub call immediately returning, which while negligible is something) and the flexibility it offers is well worth that. Smart::Comments on the other hand if not enabled are truly just comments with no overhead save skipping over during compilation (same as any other comment). The catch is that it uses mildly ebil source filtering to work so be aware (although I can’t offhand recall a time or two it ever caused problems nor actually enumerate what they were). Personally I’ve mostly moved to using l4p exclusively.

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.

[reply]

      See also Log::Any.

      The way forward always starts with a minimal test.
[reply]
Re: perl compiler optimizer curiosity
by LanX (Saint) on Mar 12, 2022 at 18:29 UTC
    > 4. is there a better way to accomplish the goal of simple on/off for debugging one's code?

    unfortunately there is no macro mechanism° in pure Perl.

    If you want code to be folded away at compile-time, you have to put it inside an if(CONSTANT-VALUE) block.

    Athanasius already showed you a way to do it.

    Tho if you want nicer syntax, you can define a (kind of) macro with Keyword::Simple which only expands the debug-code if a condition is met.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

    update

    °) Lisp like that is

[reply]
[d/l]

      unfortunately there is no macro mechanism in pure Perl.

      Technically, there is. Although using source code filters is not a good idea, it's basically a smarter version of C makros.

      perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
[reply]
[d/l]
        Sorry, if I say "macro" I mean real ones like in Lisp.

        Preprocessor macros like in C are sh*t in comparison.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

[reply]
Re: perl compiler optimizer curiosity
by cavac (Prior) on Mar 15, 2022 at 11:12 UTC

    I agree with the notion that calling a logging function which immediately returns shouldn't generate a much overhead. In a tight loop with lots of iterations (something that could make the overhead significant), i usually don't log on every iteration, only every 1000 or so:

    for(my $i = 0; $i < 1_000_000; $i++) {
    if($i % 1000 == 0) {
        debug("Foo $i");
    }
    # do some stuff
}

    [download]

    perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom