Here are the results of some sample benchmarks. These are the same as those used in the paper "Regular Expression Matching in the Wild" by Russ Cox [1].<p><pre><code> 500 MB file, regex: .*$
pcre 31.67 MB/s
re2 242.28 MB/s
pire 756.32 MB/s
500 MB file, regex: ABCDEFGHIJKLMNOPQRSTUVWXYZ$
pcre 153.67 MB/s
re2 653.76 MB/s
pire 755.98 MB/s
2 MB file, regex: (\d{3}-|\(\d{3}\)\s+)(\d{3}-\d{4})$
re2 423,76 MB/s
pire 775,89 MB/s
</code></pre>
Source: Yandex, the company where PIRE originated. [2] (Russian)<p>[1] <a href="http://swtch.com/~rsc/regexp/regexp3.html" rel="nofollow">http://swtch.com/~rsc/regexp/regexp3.html</a><p>[2] <a href="http://clubs.ya.ru/company/replies.xml?item_no=30753" rel="nofollow">http://clubs.ya.ru/company/replies.xml?item_no=30753</a>
"Pire does not have any Perlish conditional
regexps, lookaheads & backtrackings, greedy/nongreedy matches; neither has it any capturing facilities."<p>Well that rules out nearly every use case I have for needing a regex in the first place.
Cool. A very similar (concept-wise, not yet sure about implementation-wise) DFA/NFA library in Java, developed by Anders Møller at Aarhus University:<p><a href="http://www.brics.dk/automaton/" rel="nofollow">http://www.brics.dk/automaton/</a><p>I use this on Android and it performs substantially faster than java.util.regex, of course working within the constraints of DFA/NFA as opposed to the "Perlish" regular expressions.<p>Edit: And dk.brics.automaton has its own C reimplementation. I wonder how the speed and functionality compare to PIRE?<p><a href="http://augeas.net/libfa/" rel="nofollow">http://augeas.net/libfa/</a>