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]>

> "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
> 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.

Best Regards

Boost list run by bdawes at, gregod at, cpdaniel at, john at