if and elsif are basically the same speed. Of course, if your control flow changes because with elsif a lot of unnecessary tests are skipped, then it stands to reason the code as a whole will be faster, with elsif.

But please stop this micro-optimizing. You can gain a lot more by choosing a proper algorithm, than by this kind of nitpicking.

#!/usr/bin/perl

$func_refs = { '1' => \&f1, '2' => \&f2, '3' => \&f3 };

&{ $func_refs->{$arg} };

sub f1() {
   #do something
}

sub f2() {
   # do something
}
.......
[download]

I agree- dispatch table ahoy! Maybe not for three possible inputs, but it sounds like this was inspired by a greater number, or by large branched chunks of code obscuring the elsif switches.

my @lookup = (
  sub { 
     # condition 0
  },
  sub { 
     # condition 1
  },
  sub { 
     # condition 2
  },
  ... 
);
$lookup[$condition]->();
[download]

It depends a lot on what you do instead and how many cases you have to deal with. Aranging nested if statements into a binary search may speed things up a little at a huge cost in maintenance. Using a hash to dispatch to handlers rather than a bunch of if statements can have a big pay off in both execution time and maintenance if there are a huge number of cases. If there are only a small number of cases write it so it is most easily maintained - that is generally a much bigger win than shaving a few nanoseconds.

Lately, a lot of my code has had to do a lot of conditional juggling, based on the values passed to it. This is a piece of example code:
[snip] And it's fast enough for me, but it has me wondering: is it faster to use elsif for this, or to just chain the statement into a whole pile of if statements?

It is faster to write in C. Well, not really: it will probably take longer to write your program in C, but it will execute faster. So, sorry for repeating what others already wrote in this thread, but they say that repetita iuvant: if you have good reasons to be concerned by this, then by all means you should switch to C, or some other language. Otherwise you shouldn't be concerned at all and repeat the premature optimization mantra quite a number of times.

However, to remain slightly more in topic: in Perl one seldom needs long chains of if's and elsif's; even "simple" else's are often not needed as there are alternative syntactical choices with the same semantics that make for much more readable, and maintainable, code.

BTW: two relevant quotes not as widely known as Hoare's one:

Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you have proven that's where the bottleneck is.
- Rob Pike

The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it yet.
- Michael A. Jackson

do you want to always pay the overhead of 3 if checks or always pay for one if and occasionally some elsif checks? The latter is better.

Especially if you know the likelihood of the conditions in your cascade. We use the knowledge of condition statistics to tailor our cascades to accomodate the highest percentage of repeating conditions.

"Fish"