in reply to RegEx Perl Code

It just needs some repair for syntax problems:

#!/usr/bin/perl

$regex = qr/(?{print "Hey!";}).../;
$string = "some word";

$string =~ s/some($regex)/$1 x 5/e;
print $string,$/;

[download]
Your parens in $regex weren't closed. I added qr// because it's a good thing to do, and some dots to match and a substitution just to demonstrate.

Update: The 'quote regex' operator, qr//, precompiles the regex before storing it. That improves performance in the same way as m//o and s///o, but the result is stored rather than scoped as /o is. Precompilation gains nothing if the regex is only used once, but if the regex is to be stored in a variable anyway, it does no harm that I know of.

After Compline,
Zaxo

Replies are listed 'Best First'.
Re: RegEx Perl Code
by Abigail-II (Bishop) on Jul 23, 2002 at 12:28 UTC
    I added qr// because it's a good thing to do,
    Could you explain why you think it's a good thing to do?

    Abigail

[reply]
Re: RegEx Perl Code
by Abigail-II (Bishop) on Jul 23, 2002 at 17:23 UTC
    I'm not convinced that so called "compiled regular expressions" are significantly faster. Here's a benchmark, matching IP addresses. One using the 'variable' approach, and one using compiled regular expressions: 
    #!/usr/bin/perl

use strict;
use warnings 'all';
 
use Benchmark;
 
use vars qw /$ip_v $ip_re @data/;

my $quad_v   = q  '(?:25[0-5]|2[0-4]\d|1\d\d|\d\d?)';
my $quad_re  = qr '(?:25[0-5]|2[0-4]\d|1\d\d|\d\d?)';
 
my $sep_v    = q  '\.';
my $sep_re   = qr '\.';
 
   $ip_v     = qq "$quad_v$sep_v$quad_v$sep_v$quad_v$sep_v$quad_v";   
+          
   $ip_re    = qr "$quad_re$sep_re$quad_re$sep_re$quad_re$sep_re$quad_
+re";
 
   @data = map {join "." => map {int rand 1000} 1 .. 4} 1 .. 1_000; 
 
timethese -5 => {
    var  =>  'for (@data) {/$ip_v/}',
    re   =>  'for (@data) {/$ip_re/}',
};
__END__

    [download]
    Running this results in: 
    Benchmark: running re, var for at least 5 CPU seconds...
        re:  5 wallclock secs ( 5.25 usr +  0.00 sys =  5.25 CPU) @ 46.10/s (n=242)
       var:  5 wallclock secs ( 5.16 usr +  0.00 sys =  5.16 CPU) @ 45.93/s (n=237)
    Not what I call a significant win for compiled regular expressions. Perhaps you have examples where the gain is large - I've yet to encounter them.

    Abigail

[reply]
[d/l]
      Perhaps you have examples where the gain is large - I've yet to encounter them.

      jryan's benchmark code mentioned above can be tweaked with qr for a significant speed optimization. Change the line     my @patterns = ('B.B', 'CB')x10; to     my @patterns = map qr/$_/, ('B.B', 'CB')x10; in the &without subroutine.

      Your benchmark doesn't show any support for compiled patterns, and that's due to an optimization I've already described here.

      Cheers,
      -Anomo
[reply]
[d/l]
[select]

      I ran a few benchmarks here on a "contrived" large regex and large dataset; although the speed increase through qr// isn't what you'd call large, it is at least significant. Should be noted, though, that the the so-called "evil" /o was the winner in this case.

      At any rate, thats not to say qr// is bad. Personally, I think its great because it encourages modularity and readability in regular expressions.

[reply]
        When I run the benchmark you are referring to, I get a slight win for "None" over "qr". Your results showed a difference of about 10% - not what I call significant.

        I never said qr// is bad. I just argued against blindly using qr// for no other reason than <quote>it's a good thing to do</quote>. About the only benefit I've seen from qr// is that it interpolates like regular expressions, and not like double quoted strings. But the interpolation is only slightly different.

        Abigail

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom