Including the /o-modifier, the list now has 3 language features that seemed a nice idea at first, but aren't really usable now.
I've read the thread you quoted and I'm obviously missing something because in my experience /o works exactly as it should:
use Benchmark; my @words = map { chomp; $_ } (<DATA>); my $alpha = '[a-zA-Z]'; my $alnum = '[a-zA-Z0-9]'; timethese(2000, { 'Without /o' => \&testsub, 'With /o' => \&testsubo, }); sub testsub { my $count = 0; foreach (@words) { $count++ if(/^$alpha$alnum+$/); } return $count; } sub testsubo { my $count = 0; foreach (@words) { $count++ if(/^$alpha$alnum+$/o); } return $count; } __DATA__ 1500 words one per line
Which on my system shows that with /o is three times faster than without.
Using variables to give meaningful names to chunks of a regex is very useful for improving the readability, maintainability and reusability of the code. Without /o it would be inefficient. What is it about /o that makes it "not really usable"?
Update: I added this to the test script:
my $qr = qr/^$alpha$alnum+$/; [snip] sub testsubqr { my $count = 0; foreach (@words) { $count++ if(/$qr/); } return $count; } sub testsubqro { my $count = 0; foreach (@words) { $count++ if(/$qr/o); } return $count; }
The qr// approach seems to be about 20% slower than /o and qr// + /o seems to be about the same as /o alone.
In reply to Re: Never
by grantm
in thread Never-to-use Perl features?
by Juerd
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |