In short, using lc is roughly just as expensive as a simple 'eq', giving us the same results as doing a double 'eq'. Using a regex adds only a few seconds.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)
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.
In reply to Re: Function speeds: lc() vs. eq vs. =~
by Fastolfe
in thread Function speeds: lc() vs. eq vs. =~
by Clownburner
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |