in reply to Perl regexp matching is slow??

The perl regular expression engine could be seen as an example of "worse is better" (I mean it as a compliment ;-) It might not be the prettiest from some theoretical point of view, it might have pathological cases, but it exists and gets the job done. Sure, it would be great if it had no pathological cases. I have to say that I have never encountered one in real life, but I always feel a bit uneasy letting users of a website run regular expressions via a CGI script due to the risk that they will input a pathological expression just for fun (you can set a timeout, but it's a bit of a pain).

Replies are listed 'Best First'.
Re^2: Perl regexp matching is slow??
by demerphq (Chancellor) on Feb 02, 2007 at 09:56 UTC

    You could also use the expression "perfect is the enemy of good".

    Sure the perl engine is not that perfect (in fact in many respects its a heap of steaming excrement that happens to work only because some guy named Zaphod and the Infinite Improbability drive happened to be passing by at the time it was compiled), but its good enough, has proved itself to be a powerful tool and has done more than all the other regex implementations put together to advance the programming communities knowledge and exposure to regular expressions.

    Also given your link I find it amusing that rsc is from MIT. :-)

    ---
    $world=~s/war/peace/g

[reply]
Re^2: Perl regexp matching is slow??
by diotalevi (Canon) on Feb 02, 2007 at 16:29 UTC

    I think you'll find it difficult to abort the regexp engine since perl's safe-signals can be caught before and after the pattern match but not during. If you were using POSIX::sigaction, perhaps.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
      Why not make long-running instructions like pattern matches check for safe signals periodically?
[reply]

In Section Meditations