Hi Hans, On Mon, Oct 7, 2019 at 5:14 AM Hans Dembinski <hans.dembinski@gmail.com> 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-b... 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