fmt::format<Char, T> inefficiency

[seanmiddleditch]

Around format.h:2066 is the function:

template <typename Char, typename T>
void format(BasicFormatter<Char> &f, const Char *&format_str, const T &value) {
  std::basic_ostringstream<Char> os;
  os << value;

The use of basic_ostringstream is unnecessary here. The use of this template creates a new string stream - including a new string buffer - for each value without an explicit formatter.

basic_ostringstream is essentially just a specialized basic_ostream that binds to a basic_stringbuf. It's this string buffer that's the major unnecessary overhead. basic_stringbuf is an implementation of basic_streambuf that writes into a basic_string. The stream buffer is the object that does all of the actual writing and real work for IOStreams; the other classes that most users are familiar with are just a more usable facade.

cppformat could include its own basic_formatbuf that directly writes into the buffer space used by cppformat, directly applying the format parameters. This would remove any need for excess allocations or temporary string buffers. It would continue allowing the use of cppformat with any type that supports IOStreams output without (very much) overhead.

[vitaut]

Thanks for the suggestion. I did plan to implement a custom stream buffer, but didn't get around to it yet.

[patlecat]

Yeah stringstreams with a custom allocator class would be awesome and really make sense, because they are kinda slowish in STL.

[NotImplemented]

I have experimented with custom basic_formatbuf which is derived from basic_streambuf and I made it possible to write to Formatter's writer().buffer_. This solution is done to preserve ability to work with types, which support output to IO streams without any changes. However, Writer is unaware of what is written by basic_formatbuf.

[vitaut]

Awesome. Could you submit a pull request? BTW your nick looks familiar, Mike is it you? =)

[vitaut]

Fixed in d266adf.