Re: Work Backup

[grinder]

in reply to Work Backup

I prefer

sub printlog {
  print LOG @_ unless $nolog;
}
printlog "======== done =========\n";

to

print LOG "======== done =========\n"  unless $nolog;

as it makes for less clutter. It is also beneficial in that, with a little more work, $nolog doesn't have to pollute the namespace.

BEGIN {
  my $nolog = 0;
  sub setlog {
    $nolog = shift;
  }
  sub printlog {
    print LOG @_ unless $nolog;
  }
}
setlog 1;
printlog "======== done =========\n";

I like to generalise this functionality to handle debug/production screen output and/or log file output.

--
g r i n d e r

[John M. Dlugosz]

Thanks for the input.

I find the print LOG / unless to be just fine in this case, but agree that if generalized to several forms of output and modes the seperate sub would be superior. Right now, I have some duplication for things that are printed and logged. However, they are not identical — the log is more formal and needs more context.

—John

[Anonymous Monk]

Reducing clutter and generalizing is all well and good, but does it make sense to move such a small amount of logic (unless) to a subroutine? I'm under the impression that sub calls are expensive enough to not be used indiscriminately, but not too expensive to use when necessary.

[grinder]

I'm under the impression that sub calls are expensive enough to not be used indiscriminately, but not too expensive to use when necessary.

I wouldn't say that. I would say the the factoring benefits it provides (saving programmer time) far outweigh the cost benefits (having a CPU thrash around a bit). What happens if you need to change that trivial piece of logic? One change versus a multiplicity of changes, and no guarantees that you managed to locate and change all the occurrences of the call.

Another benefit comes in debugging. Supposing you have an entry printed to your logfile and a short time later the program blows up in a spectacular manner, and also suppose that for some reason you can't identify exactly where in the code this occurs, and/or it is too difficult to set a breakpoint in your own code. This happens a lot when you have a dynamic program that creates new code on the fly as it runs. The easiest solution would be to put a conditional breakpoint in the printlog routine, and then follow the thread of execution back into the main code.

Can you honestly say that you had a Perl program that was too slow, and the reason for the poor performance was due to excessive subroutine calls? What I do know is that a program with a fine subroutine granularity will lend itself admirably to Devel::DProf which will let you identify the exact points in your code where CPU cycles are being burnt.

Don't avoid using subs just because you've heard they are "slow." This runs against Donald Knuth's dictum "Premature optimization is the root of all evil". Go read A Tirade Against the Cult of Performance.


--
g r i n d e r