Re: Debug code out of production systems

[hardburn]

in reply to Debug code out of production systems

This is really easy to achive. perl will optimize away sections enclosed in if blocks with constant conditions:

$ perl -MO=Deparse -le '
> sub DEBUG () { 1 }
> if(DEBUG) { print "Debug" }
> print "Done";
> '
BEGIN { $/ = "\n"; $\ = "\n"; }
do {
    print 'Debug'
};
print 'Done';
-e syntax OK

$ perl -MO=Deparse -le '
> sub DEBUG () { 0 }
> if(DEBUG) { print "Debug" }
> print "Done";
> '
BEGIN { $/ = "\n"; $\ = "\n"; }
'???';
print 'Done';
-e syntax OK

So with a false constant, perl will replace the if with a statement B::Deparse doesn't like (but is probably a noop). With a true constant, it gets enclosed in a do block (in case there are any lexicals declared--perl doesn't look ahead far enough to know).

(And I say 'perl', not 'Perl', because it's possible that a different implementation of Perl, should there ever be one (Ponie?), may apply different optimizations.)

[liz]

If I understand correctly, this optimization is done by the optimizer, working on already compiled code. This has a number of drawbacks:
• The code must be compilable
• Effort is spent compiling, that is thrown away later
• Any BEGIN type code in there will have executed, so if you have a use in there, that module _will_ have been loaded.
To prove that last point:

if (0) {
    use strict;
}
print "INC = @{[keys %INC]}\n";
__END__
INC = strict.pm

Furthermore, to activate sections of code, no changes would need to be made to the program. It's all external with my solution. With your solution, you would have to export constant subs to all namespaces, a not so easy task and a definite pollution of namespace. Even though the optimizer takes away sections of code, there remains a coderef to the original constant in the package namespace. See this example:

sub FALSE () { 0 }

if (FALSE) {
    use strict;
}

print "INC = @{[keys %INC]}\n";
print "FALSE exists\n" if exists &FALSE;
__END__
INC = strict.pm
FALSE exists

Hope this explains some of the reasons I had for doing it the way I did.

Liz

[Abigail-II]

Effort is spent compiling, that is thrown away later

Which is done in C. A source filter spents effort filtering - doing the work in Perl. Do you have any figures that show you have some form of "gain"?

Any BEGIN type code in there will have executed, so if you have a use in there, that module _will_ have been loaded.

Depends on how you write it.

    use if 0, My::Module;

will not load My::Module.

Abigail

[liz]

Do you have any figures that show you have some form of "gain"?

No. I don't think there will be any chance of a gain until I rewrite the main conversion logic in XS. But I'm not in it for the gain of execution speed. I'm in it for the gain in the development cycle of a program.

use if 0, My::Module

Of course. But in that case I would prefer the idiom:

if (CONSTANTTOBEFALSE) {
     require My::Module;
}

or, if execution of the import routine is necessary:

if (CONSTANTTOBEFALSE) {
     require My::Module; My::Module->import;
}

I think that is much more descriptive of what is going on than the use of the if pragma.

Liz