For instance, if there are a hundred cases, and each case is taken about 1 out of 100 times, a hash based solution might be best. If all the cases are small non-negative integers, then an array based solution is to be preferred. But if one case is taken far more than any other, an if/elsif chain, with the common case first might be the most efficient solution.

Abigail

Most of the switch structures used in Perl scale linearly. They're all pretty much the same. The only exception to this is a hash that stores references to subroutines (example on page 282 of the Blue Camel).

As pg recently pointed out, hashes have an absolute worst case runtime of O(n), but that case is so unlikely that it can be safely ignored (and perl's specific implementation does tricks to help make sure it won't happen). In the common case, hashes run very close to O(1).

Note, though, that the constant value of hash searching is larger than a simple if tree, so if you have a small number of cases, the ifs might still be faster. If you're comparing integer, you could use a regular array instead of a hash, which will always give you O(1) efficiency with a much smaller constant.

use strict;
use warnings;
use Tie::Hash::Regex;

tie my %hash, 'Tie::Hash::Regex';

%hash = (
   'foo.txt'  => 1,
   'bar.html' => 2,
   '..'       => undef,
   '.'        => undef,
   DEFAULT    => undef,
);

my $arg = shift || 'DEFAULT';
my $candidate = $hash{$arg};

die "invalid arg\n" unless $candidate;
print "$candidate\n";
[download]

UPDATE:
I forgot to mention CGI::Application which uses a dispatch table to control which runmode your CGI is in. If you haven't seen it yet, you really should RTFM on CGI::App ...

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Actually, I do use CGI::Application. And I have used hashes as dispatch tables before (actually reinvented that wheel myself after dipping my toe in some assembly code). I usually use switch type statements for combining regex tests and other kinds of comparisons/tests (like in the example). I was not aware of Tie::Hash::Regex however. That is something I will rtfm on. CPAN is so massive I find it hard to keep up with it all (and that is a good thing).

UPDATE:Tie::RegexpHash also seems like a pertinent module to check out. It allows one to use regexes as hash keys.

It seems to me that you should be more interested in which method is easiest to understand. Programmer time is always worth more than CPU time. I usually use an if/elsif/else ladder since most programmers can figure out what that's doing even if they're weak on perl skills.

But if you're really interested in which is faster, develop a large data set that would cause each branch to succeed individually or all fail, and then apply that data set to a particular switch construct. Mostly though, I think you'll be benchmarking your ability to implement the switch (And the test) rather than the particular switch-style.

Update: Fine. For the pedants out there: Programmer time is almost always worth more than CPU time. Of course there are situations where execution speed is critical. In my experience though, if you're programming in perl, execution speed isn't your top concern. :-)

Programmer time is always worth more than CPU time.

That is a common myth, and understandably quite popular with programmers whose favourite programming language trades speed for programmer ease.

But in many case, it isn't true.

• In a fly-by-wire airplane, the flaps better go out right after the captain pulls the handle, delays because the company saved on programming time isn't acceptable.
• If you are one of a group of websites selling "X", and making your living out of it, it's important to attract enough customers to survive. Customers base their selection of website on several things, and speed plays a rather important role.
• If you write a chess engine, it better be fast, or else it loses on time.
• Etc, etc, etc.
Some things just need to be fast, and the program speed dropping below a certain treshhold is not acceptable. In such cases, CPU time is worth more than programmer time.

Abigail

I realize you are making a general point, but it seems unlikely that choosing the slowest switch statement implementation in Perl will cause any aircraft to go down. People learning programming should be aware that micro-optimizations of this kind rarely have any significant payoff, and are typically only worth doing after using a profiler to see where the problems lie.

There is a quite good write up by Tom Christiansen about this topic available at:

So, since there are so many ways to code switch/case constructs in perl (half a dozen in the camel book alone), which way is the most efficient as far as execution speed goes? Has anyone benchmarked this?