You can get a decent idea with a benchmark like the following:

use Benchmark;

sub asub {
    for (1 .. 2000) {}
}

Benchmark::cmpthese (5000, {
    'sub'   => sub { asub() },
    'nosub' => sub { for (1 .. 2000) {} },
});
[download]

I doubt you'll find many cases where using subroutines effectively outweighs the performance hit of loading a Perl interpreter and compiling your program in a CGI environment each time. Besides that, if you unroll subs enough, you'll probably ruin locality of reference.

Perl's more about developer ease than efficiency/small memory footprint anyway. Sometimes that matters.

As usual, it's already been done before as well. I asked this same question basically about 8 months ago I suppose. The discussion is over here at Fundamental Benchmarks. Hope this helps out!
Lexicon

1. functions are marginally slow.
2. use them anyway
3. ob-fu for speed is no better, just un-maintainable

Perl code routinely takes of several times the space and runs at a small fraction of the speed of an equivalent C program. There is nothing you can do about that other than to take up a language whose philosophy on life more closely matches your own. And if you are programming a CGI, the overhead of starting Perl itself is likely to dwarf the puny effects of your modularizing your code (which is unfortunately not free, though it is pretty cheap).

But that said, I strongly recommend that you read the chapter from Code Complete on Optimization. As he says there at length, when it comes to optimization, don't lose the forest for the trees. Concentrate on sane, understandable code. Don't worry about efficiency. And then in the time you save with good development practices, profile and optimize what needs to be optimized.

Unless you are working on simple, fast code which has to work in embedded chips, and admittedly some do, this advice results in a better development balance, and on real projects is ironically likely to wind up with faster code than people who micro-optimize from the start.

So if you have a real programming problem and Perl is a fit, then don't worry about overhead. Program sanely, try not to be stupid, pick decent algorithms, and when you are done, take Devel::DProf out for a spin if need be.

Actually, you might want to spend more time thinking about how your perl will run, not how it's written. If you are writing a CGI, you can use mod_perl on apache, Perl for Isapi on IIS, etc...

Also, I have found that using Perl2Exe can dramatically speed up a script that gets started often by eliminating the compile time.

I guess the point is that within reason, programming practice has a lot less to do with efficiency than run time implementation. Welcome to the world of interpreted languages.

That all said, use references, and avoid large hashes.

Hammy
Nothing4sale.org

Every integer you store (ok...not every one) will be represented internally as a complex 'scalar' structure which knows all about becoming a string, an object and a reference to other types of data.

Not that perl code can't be fast and efficient, but memory footprint is pretty much always going to suck compared to any non-script language.

Does this matter? Depends what you are doing

Its always good to have fast, efficient code. But its better to have readable, correct code which (in the few places it matters) does clever, less obvious things.

Less negatively, you can pack data compactly in perl using functions like pack and unpack. Function calls do have some overhead as in any language, but you could only notice that in a tight loop. There are various introspection options open to you if your perl was built with -DDEBUGGING and there are useful modules on CPAN in the Devel:: hierarchy for profiling.

But my 2p is that general coding style should be optimised for readability, with the hairy bits confined to areas which measurements have shown to be performance critical (and then only if performance is an issue or you have time on your hands).

I think you're asking the wrong question.

Don't ask, 'How long does the computer take to run this program?'. Ask: 'How long do I take to write this program?'.

You'll probably save hours of time and lots of coffee by writing the program in such a way that it's easier to maintain. Do a million milliseconds spent executing the program a million time really weigh up against the hours (one hour equals 3.6e+6 milliseconds) saved by writing it in an easier-to-maintain way, using subs?

Besides, if you're still more concerned about CPU efficiency as opposed to programmer efficiency, you'd better stick to C :-)

I'm not sure I would agree with this (throwing a bone in here to start another discussion). While I agree that one of the purposes of developing a program is to create it as lazily/quickly, readable/maintable as possible, a bigger purpose is to serve the end user of the program. While we're talking about microseconds, they can add up under exponential usage (such as IMDB using mod_perl instead of CGI scripts) and if the user can appreciate faster response times, I'm for taking more development time and serving that purpose.

My argument only holds up in those special cases, though, where the usage is enormous - so I'd answer the original pos(t)er of the question with "It Depends" (the quintessential answer of Consultants everywhere ;)) and it depends on the usage of the program.

And if you're talking about a totally different dev environment (C, Assembly, etc), where I'm not proficient in and would take significant research/dev to get proficient, Perl's good 'nuf for me (so that would be another exception to my argument ;)).

Jason

I totally agree that it depends..Let me tell you why.

I just finished a project that took a process that someone was doing by hand (going to a web site through a series of pages, copy, paste into excel...blah, blah) which took roughly 3-5 hours a day, and streamlined it down to a couple hundred lines of code that is a click-and-walk-away process of about 20-30 minutes. That's a savings on the order of 1x10³% improvement in time.

Now I could probably shave another 5-10% off of the remainder if I wanted to implement fork() in this windows2k world here in my office, but frankly, considering what they already have, I doubt the end-user is going to notice those last 2 minutes, and the headache wasn't worth it.

When it comes to implementation, YMMV. Work where you're comfortable, and determine your trade-offs. re - Time and Effort vs. Return.

Just my US$0.02 worth.

C-.