From: Roberto Hinz (robhz786_at_[hidden])
Date: 2019-10-09 14:48:49
On Mon, Oct 7, 2019 at 5:14 AM Hans Dembinski <hans.dembinski_at_[hidden]>
> "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:
> 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
Anyway, it's clear now that my statement is a bit reckless.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk