|No such thing as a small change|
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