|No such thing as a small change|
sexegerby japhy (Canon)
|on Sep 21, 2000 at 01:56 UTC||Need Help??|
as modified from my Perl5-Porters post
If we're able to look at the specific nodes of a regular expression, then we should be able to create a regex that works from the BACK of a string to the FRONT. What do I mean?
That regex finds the last occurrence of digits in $string. Now, it's not all that bad, but it could be made a great deal simpler by:
Now, the regex (\d+)(?!\D*\d) can also be written as (\d+)(?=\D*$). If digits aren't followed by another digit, then they are followed by only non-digits, if anything. In the process of reversal, the look-ahead can be eliminated, since the regex would be \D*(\d+) which has a redundant leading "node", \D*. The regex's meaning is not changed by its removal.
We already have re.pm which can pick a regex apart during compilation and during the actual matching stage. This has the ability to pick apart individual nodes of a regular expression.
Note: the term "node" refers to a combination of regex atoms and quantifiers which can match a given substring backwards or forwards. In the regex \d+[abc]def(foo|bar), the nodes are: * technically, the two o nodes can be combined hereFor the mean time, there is no way to automatically reverse a regex. You have to do it by hand. But the benefits of it are amazing. Maybe they need to be seen to be believed. If so, here is an example.
You have a simple programming language, called KC ("kinda crummy"). It has a VERY simple grammar:
We can write a regex to match an entire file (shown above). Oh, before I go any further, here's the sample program:
Let's say we wanted to extract the LAST comment from this program as well as be sure it was coded properly. Here's my regex. Note: I used the "cut" regex operator (?>...) which matches without allowing a backtrack, to speed up the non-string, non-comment part.
I'll also implement a reversed version. The reversed terms for the grammar are:
If you look long enough (it shouldn't take too long) you'll see that EACH node of the terms has been reversed properly. Now, I ran a benchmark (available on my web site -- follow the links for "Sex, Eger!") and it showed that the reverse method was actually faster than the forward version, EVEN with having to reverse the input string AND the value of $1. When I implemented a cached version, where the reverse of $CODE was already stored, it was even faster (obviously). Here are the wonderful results:
This is, to say the least, very good. The backwards version runs %33 faster, and the cached version runs %50 faster!
If we already know the KC code is well-formed (that is, it will match the entire-code regex), then we can eliminate a lot of the code in the regexes. First, to match the last comment, forwards:
And now backwards:
The benchmark gave me the following data:
Another tremendous difference. The backwards version is %100 faster, and the cached version is %150 faster!
What does this mean? Perhaps you should look into rethinking how you match your strings. If you're looking for the last of something, or for something towards the end of a string, and the string is potentially large, thinking about regex reversal. It could save you a lot of time.
This text will be updated and modified at my web site. I'll put headings in, and all that fancy stuff. :)
Jeff "japhy" Pinyan