> so, I think you'll see parsing dwindle to almost nothing and your > Can you create thread-local match_results objects and reuse them? If That might well be fast enough to keep the Xpressive version
#XPRESSIVE CODE#
> Whoa! The performance just shot up to a mere 6X the custom code (from You can still make the regex objects static const and use placeholders I did make the sregex's const that appears to have improved performance a bit. Unfortunately, the semantic actions reference local variables, so I don't think I can make the sregex's static (please correct me if I'm wrong, but I can't see how multiple parallel invocations of the function could reference separate stack variables from static sregex's). > I'm sorry, I read your original suggestion as being the same as Eric's: reuse the match_results. > How about making them static const? That should be thread safe. > I'm testing means I can't do that otherwise. > with the benchmark performance, the nature of the function > If you make them static or move them out of the loop, it > Each call to parse() is constructing the sregex variables. Return static_cast(std::floor(_value + 0.5)) Raise_extract_failed(_description, _value) I'm not certain I understand where to apply keep(), but I'll have a go at it.įYI: bar::to_number() calls strtod(), strtol(), etc.įoo::extract(char const * & _input, char const * const _description, (A function local static would suffice but then the function wouldn't be thread safe.)
The function is called in a one-off fashion that wouldn't permit keeping the match_results object, unfortunately. > not require backtracking, so you could use keep() to turn Also, many of the quantifiers in your grammar do > should reuse the match_results object to avoid extra memory With each call to parse(), you construct and > From looking at the code, I can see a few areas for
#XPRESSIVE FREE#
Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument.
Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. IMPORTANT: The information contained in this email and/or its attachments is confidential.
#XPRESSIVE SOFTWARE#
Rob Stewart Engineer, Core Software using std::disclaimer Std::cout << timer.elapsed() << "s elapsed (total = " << total ')' If (!regex_match(_value.begin(), _value.end(), match, price)) > (real | whole_number | fraction | integer) ignore leading zeroes to avoid octal parsing Return static_cast(std::floor(value + 0.5)) īoost::xpressive::function::type const direct = Int const whole(bar::numeric_cast(_whole)) ĭouble const value(160000.0 * whole + _fraction) Operator ()(Value const & _whole, double const _fraction) const Return static_cast(std::floor(fraction + 0.5)) Unsigned const denominator(bar::numeric_cast(_denominator)) ĭouble const fraction((160000.0 * numerator) / denominator) Unsigned const numerator(bar::numeric_cast(_numerator))
Operator ()(Value const & _numerator, Value const & _denominator) const Int64_t result(bar::numeric_cast(_value)) ĭouble const value(bar::numeric_cast(_value)) It is semantically equivalent to lexical_cast. :-} )įYI: bar::numeric_cast winds up calling strtod(), strtol(), etc. I gave up and decided I'd wait until I can use a newer release before I fight that fight again. (BTW, I tried using Spirit.Qi for this - with Boost 1.37 - but never could get things to compile. Have I done anything to make it really slow? Can it be made faster? I have included the Xpressive code and the performance testing code below for your study. The Xpressive code is over 175X slower than the custom code. I was experimenting with Xpressive to see how it would compare with some custom, string-based numeric input parsing.
0 kommentar(er)
