Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.c++ Subject: Re: rational numbers Date: Wed, 29 Sep 2021 10:34:03 +1300 Lines: 56 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net FXUCcHsTDjo/aUCL5jJRPAldzTLKfbhoPs6PPfIrJfns6tsJ2n Cancel-Lock: sha1:JZUHQowJ7/IDdZKtzedO9cXSjqI= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Language: en-US Xref: csiph.com comp.lang.c++:81656 On 28/09/2021 23:23, Paavo Helde wrote: > 28.09.2021 07:53 Juha Nieminen kirjutas: >> Paavo Helde wrote: >>> 27.09.2021 08:36 Juha Nieminen kirjutas: >>>> Paavo Helde wrote: >>>>> Adding a stream adaptor for a class having only a to_string() is trivial: >>>>> >>>>> std::ostream& operator<<(std::ostream& os, const A& a) { >>>>> os << a.to_string(); >>>>> return os; >>>>> } >>>> >>>> While you are at it, why not just output the contents of that A object >>>> directly, rather than making it construct a string? >>> >>> Because of speed. I just showed elsethread that serializing a large >>> object into an in-memory string can be up to 10x faster than writing it >>> into a std::ostream piece-by-piece. >> >> Suppose that the 'a' object above consists of 2 large strings, and you >> want to write them to 'os' concatenated. > > This is another task. If you already have data formatted into strings, > then of course these can be written directly to a file. But for that you > don't need a C++ std::ostream interface, you can write directly into the > file descriptor, or C++ streambuf(). If there are only a handful of > strings, then you can of course write them to the stream as well, the > overhead is insignificant. > > What I'm talking is about outstreaming millions of small items > one-by-one, like advocated by ostream<< enthusiasts: just define a > proper operator<< overload and write everything in the ostream, > recursively, each number separately. > > It's this formatting interface of C++ iostreams which is slow. With > MSVC++ I just stepped though an operator<<(std::ofstream&, int), this > involved at least 2 virtual function calls, 4 locking/unlocking of > current locale, and consulting TLS about the number of uncaught > exceptions, not to speak about tens of non-virtual function calls (which > hopefully get optimized away) and twiddling with the stream state. This > is all 100% unnecessary overhead for formatting an int in C locale. It > won't matter for a single debug printout line, but it will matter when > exporting a 100,000 line table into a CSV file. Ah, right so it's the overhead of locale based formatting that's the real problem here. Presumably this would be the same for C printing functions as well. I can see why std::to_chars would have an advantage here. I haven't seen such an high overhead on Unix/Linux, I wonder of the Windows way of doing things is more burdensome? An example wit timings would be useful! -- Ian.