Menu
I'm looking for a performance comparison between perl and boost regular expression.
I need to design a piece of code which relies very heavily on regular expressions, and can choose between:
I know perl is known for it's optimized string processing. However, I can't find a performance comparison to boost regex library.
Do you know of any such comparison?
Thanks
335
In general, Perl uses a backtrack regex engine. Such an engine is flexible, easy to implement and very fast on a subset of regex. However, for other types of regex, for example when there is the | operator, it may become very slow. In the extreme case, its match speed is exponential in the length of the pattern.
Being more specific with your regular expressions, even if they become much longer, can make a world of difference in performance. The fewer characters you scan to determine the match, the faster your regexes will be.
Regular Expression (Regex or Regexp or RE) in Perl is a special text string for describing a search pattern within a given text. Regex in Perl is linked to the host language and is not the same as in PHP, Python, etc. Sometimes it is termed as “Perl 5 Compatible Regular Expressions“.
In the 1980s, the more complicated regexes arose in Perl, which originally derived from a regex library written by Henry Spencer (1986), who later wrote an implementation of Advanced Regular Expressions for Tcl.
The startup cost of running a Perl interpreter from within your application (via the system function I presume) will outweigh any benefits you gain over using Perl's regex engine. The exception would be if you have a VERY complicated regular expression that Perl's regex implementation happens to be optimised for but boost's regex engine isn't.
The real answer is that I do not know of any such comparison, but Perl's regular expression facilities are not necessarily the fastest. See here for some information about an algorithm that beats Perl's regular expression for some expressions.
EDIT: It is possible to overcome the startup cost of starting a full perl interpreter by linking to libperl or using libPCRE. And using boost will probably give you more flexibility and performance tuning options if you need them.
Final Note: There are no known direct comparisons between boost.regex and Perl's regex in terms of performance. The solution is to try both and see which is more performant for the OP's specific situation.
(Edit : There is now a good comparison between Boost and PCRE. See http://www.boost.org/doc/libs/1_41_0/libs/regex/doc/gcc-performance.html)
139
If you haven't seen it yet, there's a regexp benchmark in the Great Language Shootout. It doesn't rank Perl very high at all. A Boost implementation using boost::xpressive is ranked first (which pre-compiles the expression at compile time). However, this is a microbenchmark, so probably not representative of general regular expression speed, but still worth a look.
Surprisingly enough, apparently the fastest regular expression engine by far is Google Chrome's V8 JavaScript JIT (almost beats GCC in wall-clock time, utilizing just a single CPU core)
27
If your regular expressions are fixed at compile time, you could also consider Boost.XPressive. It allows one to write regexes as expression templates that are parsed at compile time.
37
Start with the simplest solution. Decide how fast it needs to be for your application. Then measure the speed. If it's too slow, try the harder solution. Measure again. Repeat as necessary.
While my gut agrees with most of the other answers saying that starting the interpreter will be more expensive, you'll never know until you measure.
There's "fastest possible" and "fast enough for your application". Don't add complexity to get the former if you already have the latter.
33
Unless your regex is insanely complex (for which perl's regex engine is incredibly fast by the way) then as other's have said, your overhead is in interpreter startup. On the other hand you could run a persistent perl that provides a regex server quite easily.
31
If you really need fast you can get a REGEX content coprocessor. There are two that I know of. Titanic makes a range of processors. Another is made by Cavium. And finally, LSI bought out a smaller company, and is shipping a line of regular expression matching processors.
Theses systems can execute thousands of regular expressions in parallel, rather than one-at-a-time. The most expensive part of using them is moving memory to them and moving them back, and dealing with block-limits, etc.
But if performance is a concern, you might want to try these out.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
