Firstly, none of your cases are the same. You could use:

if(  $type =~ /^CR\Z/i  )
# or
if(  $type =~ /^CR$/i  )
# if you want to allow for ignoring trailing newlines
[download]

I'd argue that the speed difference is of extremely little importance in this case.

Use whichever makes the most readable code. So that eliminates the second one in my book. I like the first one.

Good point, but I guess I should have been more precise about my situation, you see the database will only ever be in two states, cr or CR and never Cr or cR. So while checking for the last two states is OK it's really not required and if you're going to give each option as separate it's not really required.

But thanks! I never played with Benchmark before, now I have new perl toys to play with! :-)

---

Signature void where prohibited by law.

use Benchmark 'timethese';

sub eq_alone    { $_[0] eq 'cr' || $_[0] eq 'CR'; }
sub lc_eq       { lc($_[0]) eq 'cr'; }
sub regex       { $_[0] =~ /^cr$/i; }

timethese (2_000_000, {
        eq_alone => sub { eq_alone('cr'); eq_alone('CR'); },
        lc_eq    => sub { lc_eq('cr');    lc_eq('CR');    },
        regex    => sub { regex('cr');    regex('CR');    },
});

__END__

Benchmark: timing 2000000 iterations of eq_alone, lc_eq, regex...
  eq_alone: 22 secs (21.48 usr  0.00 sys = 21.48 cpu)
     lc_eq: 22 secs (22.76 usr  0.00 sys = 22.76 cpu)
     regex: 25 secs (24.88 usr  0.00 sys = 24.88 cpu)
[download]

In many cases like this (where the numbers are so close), performance matters less than readability. Use whatever is easier for you to comprehend and easiest for future maintainers to read. I usually vote for using lc in cases like this.

I did a benchmark and came up with the following:

    Benchmark: timing 1000000 iterations of eq, lc, re...
        eq:  3 wallclock secs ( 2.76 usr +  0.00 sys =  2.76 CPU)
        lc:  3 wallclock secs ( 2.69 usr +  0.00 sys =  2.69 CPU)
        re:  3 wallclock secs ( 3.13 usr +  0.00 sys =  3.13 CPU)
[download]

You *really* don't need to worry about the differences in speed, unless you're doing this 100000 times or something like that.

Seriously: don't try to optimize things like this. Testing case-insensitive equality is *such* a fast operation that you shouldn't be worrying about it--yes, even in an interactive situation.

Instead worry about Getting It Right. For example, what does your second code snippet do if $type is 'Cr' or 'cR'? Maybe you don't think you need to worry about those things, but I say you should: it's definitely more important than worrying about a couple of milliseconds per every 100000 case-insensitive equality checks.

I'm guessing =~ is the slowest, but Benchmark will tell you
                - Ant