Regular expressions performance: Boost vs. Perl [closed]_问答_开发者

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

开发者_如何学Go

Closed 8 months ago.

Improve this question

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:

running it through a boost regex
dispatching a perl interpreter and do the work in perl

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

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)

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)

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.

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.

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.

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.

The perl interpreter is going to be a fixed cost. If the time saved by running your data through the interpreter greatly outweighs the interpreter costs(ie, you have a lot of data), you will have a performance boost.

It's probable that you're best of with pure C++ here, just because of the process invocation.

Sorry, I don't have data. Love to see your test results though.