Re: [boost] [lexical_cast] Fast conversion from boost::iterator_range<std::string::iterator>?

Subject: Re: [boost] [lexical_cast] Fast conversion from boost::iterator_range<std::string::iterator>?
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2012-01-20 14:14:40

Sorry for not writing for a long time, totally forgot about this thread.

2011/11/23 Matthew Chambers <matt.chambers42_at_[hidden]>:
> I too would like to see
> optimized conversions work on string ranges; what's the point in doing a
> fast conversion if you have to do a string copy first? :)

There are a lot of libraries, that can have tuned conversions for
lexical_cast. The bad thing, is that lexical_cast can be customized
ONLY via overloading operator>>(stream&) and operator<<(stream&), and
that is not very fast. That is the design. As simple, as possible.
Multiple customization points will make the design obfuscated.

It would be also a bad idea, to include a lot of different library
headers to lexical_cast.hpp (will increase compilation times, add
unnecessary dependencies...)

2011/11/24 Matthew Chambers <matt.chambers42_at_[hidden]>:
>
> On 11/23/2011 11:55 AM, Olaf van der Spek wrote:
>
>> On Wed, Nov 23, 2011 at 5:55 PM, Matthew Chambers wrote:
>>>
>>> On Oct 13, 2011 Michel Morin wrote:
>>>>
>>>>  - Assuming it is safe to use `std::atoi`,
>>>> `std::atoi(&iter_rng.front())` is faster
>>>>    than both of the above two methods.
>>
>>
>> Is front() guaranteed to return a 0-terminated string?
>
>
> Certainly not. I consider that caveat to be part of the "assuming it is
> safe" precondition.

If you assume, that it is safe to use &iter_rng.front() (extremely
unsafe!), you can add overload for lexical_cast to the
iterators_range_io.hpp. Something like this:

template <class OutT>
OutT lexical_cast(const iterator_range<char>& iter_rng) {
  return lexical_cast<OutT>(&iter_rng.front());
}

Then it will benefit from all the char* optimizations.

2011/11/28 Matthew Chambers <matt.chambers42_at_[hidden]>:
> Finally, I got lexical_cast down to its best performance with
> BOOST_LEXICAL_CAST_ASSUME_C_LOCALE (again using MSVC 10). There is some kind
> of optimization going on with the iterator_range->string branch, so let's
> ignore that. I added a sscanf line for better comparison with
> http://www.boost.org/doc/libs/1_48_0/doc/html/boost_lexical_cast/performance.html

Thanks for that info. It looks like std::locale class has a totally
different implementation under VC. I`ll take care of that and tune
lexical_cast implementation for VC.

> Still we see that lexical_cast is quite slow for string->float (at least on
> MSVC 10) which doesn't match the GCC results on the performance.html page
> and it's abysmal for converting iterator_ranges.

Not string->float. You are using string->double conversion. Under VC
it is not tuned, because a tuned version is not exactly precise. And
trading accuracy for speed is a questionable solution. By the way,
last time I was looking through the Spirit implementation, it was
fast, but not perfectly accurate (incorrect values in 18-20th sign
after dot)

> I'm hoping Antony Polukhin will chime in and say how hard it would be to add
> iterator_range specializations and redirect the existing string->T
> specializations to forward to the iterator_range ones. I don't understand
> the TMP in the new lexical_cast. Also, [Antony] please add something like:

Optimizations for iterator ranges will not be added in nearest releases.

> "Tests were compiled with BOOST_LEXICAL_CAST_ASSUME_C_LOCALE defined for
> optimum performance." to the test description on the performance.html page?

They were compiled without BOOST_LEXICAL_CAST_ASSUME_C_LOCALE.
Differences between GCCs and VCs implementations of std::locale are
huge. I`ll optimize lexical_cast for VC soon.

Best regards,
Antony Polukhin