A faster way to compile code out of a system is to hide it behind an if(CONSTANT) or unless(CONSTANT), as in

  use constant DEBUG => 0;
  if (DEBUG) {
    warn(
      "This code is only compiled into the program ",
      " when DEBUG is true.\n";
    );
  }

[download]
The bonus is that you don't introduce more delay in the compile time, which a lot of people apparently dislike. I discovered this in POE, a project where I gained about 20% runtime performance with POE::Preprocessor by replacing small, commonly used functions with macros. A contrived example: 
  macro num_max (x,y) {
    ((x) > (y) ? (x) : (y))
  }

[download]

This macro is then used, template-like, in the main body of source as:

  print "You owe: \$", {% num_max $total-$paid, 0 %}, "\n";

[download]

Back to compile-time inclusion. POE::Preprocessor uses the common if/elsif/else syntax, tagged with an "# include" marker. That is, if you comment a construct with "# include", it will be evaluated at compile time (using the CONSTANT trick), and the code in the block will be included (or not) depending on the condition's outcome.

  unless ($expression) {  # include
    ... lines of code ...
  } elsif ($expression) { # include
    ... lines of code ...
  } else {                # include
    ... lines of code ...
  }                       # include

[download]
Problems with macros and source filters in general:
  1. They alter your source's line numbers, which interferes with warnings and error messages. POE::Preprocessor takes great pains to insert "# line" directives that not only preserve your original line numbers but also indicate where in your macros the problem may really lie.
  2. They confound packagers, most notably perlapp and perl2exe. These Perl "compilers" do not evaluate source filters at runtime. They don't even evaluate them at "compile" time. Instead, the original, non-Perl syntax becomes an error when you try to run things.
  3. Source filtering is slow. I got no end of complaints about slow startup times, even though POE::Preprocessor attempts to be optimal Perl.
  4. Any non-Perl syntax, no matter how trivially like any number of template toolkits, is greeted with shock and confusion. (Heck, people still don't like @_[CONST1, CONST2], even though it is standard Perl syntax.)

Liz's solution is much smarter than mine. It addresses all these problems. Very nice!

-- Rocco Caputo - rcaputo@pobox.com - poe.perl.org

In reply to Re: Debug code out of production systems by rcaputo
in thread Debug code out of production systems by liz

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.