Is there a significant performance penalty for calling a subroutine vs inline code?

Old school question - I don't know how efficient the running of Perl is.

I have a group of if/elsif/else statements that process lines of data for different data types that come in the report.
I find it easier to read and look at the code if I use subroutine calls instead of variable sized chunks of inline code.

Some older languages had significant penalties in handling the calls so that is was faster to include short routines inline rather than call them.
I do not need to pass variables with the call. The line being read has all the data and the significant items are put in variables to be processed later.

Probably not a critical bit of knowledge to have but I try to make my programs efficient and be readable.
I already have the chain of ifs so that the most common ones are checked first.

I have written the code inline. I have no way to actually measure how fast it runs. Since it processes things every 15 minutes, I don't want to tie up the files anymore than necessary.

Perl sub calls have a lot more overhead than function calls in most programming languages, however it's still a relatively small amount of overhead compared to things like file IO, network accesses, etc. Unless you're calling a function many thousands of times, there's going to be little advantage to inlining it.

One thing you mentioned stands out to me:

> I do not need to pass variables with the call.

This actually gives you a significant optimization possibility.

Instead of calling your function which handles the line as foo(), call it as &foo (with an ampersand and no parentheses). When a function is called in that way, this is a signal to Perl that the function takes no parameters, so Perl will avoid setting up a new @_ array as part of the call. This saves a bit of overhead.

(A side-effect is that the function will now be able to see its caller's @_ array!)

This is a very general question without concrete code, which can only be answered in general terms.

Yes function calls are relatively slow, but this only shows when you scale massively, like with O(n^2)++ complexity and/or recursive calls.

Normally improving the algorithm with standard mechanisms pays off far better than micro optimizing the calls.

For instance in your example using a "dispatch table" $call{$type}->() instead of if/elsif/else chains sounds better, O(1) vs O(n)

"Memoizing" also comes to mind to avoid repeated calls via cached results.

So the first thing that you should do, when in doubt is benchmarking.

For instance one major overhead beside the call itself and connected stack/frame mechanics is copying from @_ and declaring/initializing variables, especially arrays.

So using common "closure vars" could prove to be much faster.

FWIW, contrary to your assumption are inlining and readablity not opposed to each other.

You can always use eval to construct complex code from smaller snippets. Text manipulation is Perl's forte after all.

There are also more comfortable "macro" mechanisms available on CPAN.

=== update

Another technique I used in the past to avoid trivial functions are goto LABEL statements.

Especially in your scenario with if/elsif/else chains where the usual point of return for all snippets is a END_LABEL: behind the chain.

The advantage over inlining is that repeated snippets won't lead to bloated code, and this without noticeable performance penalty.

Again only use those techniques after the benchmarks prove them necessary!

Perl's function calls are costly, comparatively. A good discussion of that has already been offered, but then ultimately you can benchmark.

Given that no specifics are given here's a very basic example, adjust and expand as suitable. I only test a sub with arguments because I can't easily conjure realistic code, for which we wonder about the sub call overhead, without any arguments.^†

use warnings;
use strict;
use feature 'say';

use Benchmark qw(cmpthese);

my $count = shift // 10e6;   # iterations; test code too simple for lesser no

sub has_caps {                               # very simple test code
    return $_[0] =~ /[A-Z]/;
}
   
my $str = join '', 'a'..'z', 'A', 'a'..'z';  # test string

#sub w_sub_noargs { }                        # a realistic example?

sub inline {                                 # "see" string from higher scope
    my $flag = $str =~ /[A-Z]/;
}

sub w_sub_args { 
    my $flag = has_caps($str);
}

die "Unequal! (", w_sub_args(), ' vs ', inline(), ")" 
    if w_sub_args() ne inline();

cmpthese( $count, {
    w_sub_args => sub { w_sub_args() },
    inline     => sub { inline() },
})

This prints

                Rate w_sub_args     inline
w_sub_args 2518892/s         --       -41%
inline     4273504/s        70%         --

on a quiet server, and a very similar ratio on an older desktop.

There is a difference, but this is a lot of runs, 10 million. (The code is so light that for a lesser number of calls, even 1e6, I get a warning too few iterations for a reliable count.)
So the difference per call is minuscule, ~0.16<code>&mu;s</code> (1/2518892 - 1/4273504), and it does take a lot of calls even for a small saving in runtime (~6 million calls for one second difference).

Note that simple code here emphasizes the overhead (even as starting the regex engine isn't all that cheap). With more work in the sub the relative difference is lesser. On the other hand, I never unpack the arguments above but directly use $_[0], and that reduces the overhead. (But this is something one may want to do, for simple code with performance concerns.)

So put some realistic code in there, with a realistic number of iterations. If there is indeed a way to write a function for it that doesn't need input^&dagger; then just add it to the benchmark.

But, in short -- is it worth it? Just how many calls does the real code make, and what is a total runtime? Saving milliseconds may matter but microseconds don't, not in a scripting language.

Keep in mind that making sure to compare (strictly) "apples to apples" in benchmarking can be tricky. Thanks to ikegami for comments.

A few general benchmarking notes.

It's often more convenient to use cmpthese( -$runfor, ... ), where $runfor has the number of seconds to run the test for (a 3 or 10 is often plenty
jjjj).

It turns out that running the benchmark as

cmpthese( $count, {
    w_sub_args => \&w_sub_args,
    inline     => \&inline,
})

results in a larger difference, about 80%. (We can do it here since the subs need no arguments.) Not a game changer, but if benchmark's own overhead affects results then it is more accurate to do it without that overhead. (I though that results are computed without the overhead but perhaps not everything can be accounted for?)

^&dagger; What data would that code work with?

If the sub takes data from outside, via a a file or network or a socket or such, then that easily dwarfs a function call overhead, probably by order(s) of magnitude.

If it relies on data "seen" in its scope then that's in general bad practice and usually indeed a bad idea. For one, it's prone to possibly subtle errors, specially as the code is tweaked later.