in reply to storing a qr// compiled regexp in a database?

Your "precompilation" won't gain you anything, but it's easily possible:

my $compiled_regex = qr/$regex/;

my $sth = $dbh->prepare("insert into regexes name,value (?,?)");
$sth->execute("ready_to_eat", $compiled_regex);

# later

my $sth = $dbh->prepare("select value from regexes where name = ?");
my $rc = $sth->execute("ready_to_eat");
my @values = map { $_->value } $sth->fetchrow_array({}); # or somethin
+g, look in the DBI docs

# convert back to compiled regex
for (@values) {
  $_ = qr/$_/;
};

[download]

Replies are listed 'Best First'.
Re^2: storing a qr// compiled regexp in a database?
by ManFromNeptune (Scribe) on Sep 17, 2005 at 21:16 UTC
    aren't you just re-compiling the regexp here? 
    $_ = qr/$_/;

    [download]
    My goal was to shave off some performance overhead since I have lots of complex regex patterns that need to run fast.

    I had thought of just keeping the precompiled patterns in memory (like in %precompiled{$regexkey}), but since the patterns come from a database in the first place, then I have potential staleness if the db gets updated since the Perl app started (mod_perl, btw.)
[reply]
[d/l]

      A "precompiled regex" is mostly a string, at least from the Perl view of things. And the best you could do to save a regex in a database is to stringify it and then recompile it from that string anyway.

      I think you're looking in the completely wrong direction if you're trying to optimize such minor things. Have you profiled your application already? Does it really spend that much time on compiling (and recompiling) regular expressions? Maybe you should reduce the number of regular expressions then. A good profiling tool is Devel::Dprof. It's also the only profiling tool.

[reply]
        Ok, I think this is sound advice. I haven't used Dprof, but I have done some more hackish profiling with TimeHiRes. Since my regexes are actually user-defined, I notice that in some cases they take an enormous amount of processing... for example, a 60kb web page will consume 18 minute of CPU time crunching a complex regex! But the stem of the problem is that I don't have much control over the regex that the user defines, hence I'm still looking for any perf gains. Perhaps I should devise a way to help optimize the users' regular expressions (probably not a simple thing to do aside from end user education.)

        Anyways, this is a classic case of programmer (me) vs. end user (with wacky regexes.) Sigh...
[reply]

In Section Seekers of Perl Wisdom