Boost logo

Boost :

From: Roberto Hinz (robhz786_at_[hidden])
Date: 2019-10-09 14:48:49


Hi Hans,

On Mon, Oct 7, 2019 at 5:14 AM Hans Dembinski <hans.dembinski_at_[hidden]>
wrote:

> "It’s impossible to achieve a good perfomance. std::ostream does not
> provide direct access to the buffer. to_base64 needs to call member
> functions like write or put for every little piece of the content, or to
> use an itermediate buffer."
>
> It is not impossible to achieve good performance, page 68 of
> http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf list problems,
> which are solvable.
>
> In practice, increasing the buffer size helps and turning off
> synchronisation with stdio:
>
> https://stackoverflow.com/questions/5166263/how-to-get-iostream-to-perform-better
> The SO answer lists several examples were C++'s iostreams beats C's stdio
> in performance.
>
> Your argument is also not convincing. Just calling member functions
> doesn't make something slow if you compile with optimisations, which is a
> must with C++. (...)
>

Thanks for the feedback. I removed that part from the docs.

I did some benchmarks. First I implemented a base64 encoder
using outbuf and std::streambuf and I couldn't find any
conclusive evidence that any one is faster than the other
( I get different results from seemingly irrelevant
code changes ). Then I implemented a simple json writer.
In this case the streambuf buffer was about 30% slower than
the outbuf version. Not a tremendous difference.

I choosed to write directly into streambuf instead of ostream
so that we can disconsider many of the possible QoI issues
related to std::ostream. That article you reference seems to
only address optimizations on facets usage and formatting,
which I think should not have any effect in these benchmarks.
That SO discussion seems to not apply either, since
the streambuf I used does not write into a file but
solely to char array.

The benchmark implementations are available at
https://github.com/robhz786/outbuf/tree/master/performance

Anyway, it's clear now that my statement is a bit reckless.

Best Regards


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk