in reply to Re: Debug Macro
in thread Debug Macro

No this doesn't help. You're still paying the cost of a function call. And function calls are s-l-o-w in Perl.

I recently encountered a program of which 20% of the run time was being absorbed by a debug() that was being called to do nothing. (postgrey, in case you were wondering).

My solution was to change the code to

debug("foo") if DEBUG;

... but only because I was worried about performance. From a readability point of view, it sucks.

True macros would be a nice addition to Perl. I know that there's a Macro module that purports to do just this, but I have never used it.

• another intruder with the mooring in the heart of the Perl

Replies are listed 'Best First'.
Re^3: Debug Macro
by Ovid (Cardinal) on Mar 27, 2007 at 13:17 UTC

    If you want a nice project, you could write PPI::Macro, a macro system based on PPI. Not sure how much work it would take, but I know that many folks would be quite happy with this.

    (Or you could wait for Perl 6 and its true macros, but your beer might get warm while you're waiting)

    Cheers,
    Ovid

    New address of my CGI Course.

Re^3: Debug Macro
by sgt (Deacon) on Mar 27, 2007 at 22:49 UTC
    No this doesn't help. You're still paying the cost of a function call. And function calls are s-l-o-w in Perl.

    actually with filtering you don't pay for it, it is there or not (a bit like when you use dynamic linking and you switch some instrumenting lib for a non-instrumenting one -- so you can use a wrapper)

    then with code like this

     foo() if $foo;

    why do you pay for a function call?

    anyway your comment reminds of that perl command line flag (-P) that calls the C preprocessor on your code... maybe it could be useful for this can of debugging?! (chess notation)

    cheers --stephan p.s by the way for me true macros are lispish macros, the others do textual substitution (meaning not caring about syntax) and that can break easily like perl filters or cpp)
      actually with filtering you don't pay for it

      Do you mean source filtering? I cannot, in all honesty, recommend this approach. It's fun to play with, but I consider that in general it's a glorious experiment that failed magnificently. I'd like to be proved wrong though, but I doubt big systems in production use filtering.

      then with code like this foo() if $foo; why do you pay for a function call?

      You don't, but I find that the added noise of the statement modifier is annoying. It's there to avoid paying the cost of the function call, but it extracts its own price on the overall readability of the program.

      I also expressly declined to mention the -P switch. Are you aware of all the caveats that apply to its use? Check out perlrun. For me, having to jump through hoops to avoid $var =~ s/foo// would be a right hassle.

      And yes, we're on the same wavelength: when I said "true macros", I meant true macros, not the toys that comes with a C compiler.

      • another intruder with the mooring in the heart of the Perl