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
| 