Subject: Re: [boost] [xpressive] Performance Tuning?
From: Eric Niebler (eric_at_[hidden])
Date: 2009-07-06 18:56:55
Stewart, Robert wrote:
> Dave Jenkins wrote:
>> It's disappointing that locating a match_results object in
>> thread-local storage takes approximately the same amount of time as
>> default constructing a new one. I had hoped for better.
> I just noticed that while my TLS accessor
> returns a reference to the smatch, I saved it to a copy rather than a
> reference where I was using it. Correcting that mistake shows the
> Xpressive code taking around 1.5X the time used by the custom code.
That's much better than 175X slower!
> I've seen added more test cases and updated the custom code and must
> now correct some things in the Xpressive code to handle all of the
> same cases before I can do any more measurements.
At this point, most of the low hanging fruit is picked clean. If you are
hungry for even more performance, you can eliminate the nested regex
invocations by changing the definition of the regex objects from this:
static const sregex zero = as_xpr('0');
static const BOOST_PROTO_AUTO(zero, as_xpr('0'));
Do this for all but the top-most regex (the one named "price" in your
first example). You must also #include <boost/proto/proto_typeof.hpp>.
When I do this, performance drops from 9.5s to 6.0s.
> With TLS, a straightforward performance test required about 68s,
> whereas with a function local static, it required about 65s.
> Keeping the static smatch and omitting the semantic actions changed
> the time to about 40s.
> From that, one can conclude that the matching takes about 40s, the
> semantic actions add 25s, and the TLS lookups add an additional 3s,
> in a loop of 100,000,000 iterations.
Very interesting. Thanks for the measurements.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk