<format>: Improve performance

[StephanTLavavej]

Reported by @jovibor - here are examples where <format> is 20% to 70% slower than libfmt:

#1800 (comment)
#1800 (comment)

[AdamBucior]

The issue is probably caused by not preallocating any memory for the output string. I think reserving the size of the format string would be a good guess.

[MikeGitb]

The issue is probably caused by not preallocating any memory for the output string

Shouldn't the strings from the benchmark fit into the Small String Buffer and not need allocation at all?

I think reserving the size of the format string would be a good guess.

At least for simple formaters, I think this is almost guaranteed to be too short {} is only two bytes. Integral numbers only fit in that for very small values, floating point will essentially always require more and if the argument is a string or some more complicated type just two chars will also almost never be enough.

Not that I have a good counterproposal, but usually, it is better to overallocate by a few bytes instread of allocating just not enough and having to reallocate.

Any idea what fmt does? Are you even allowed to look at the fmt source code?

[ZaldronGG]

The "interpolated strings" feature in C#, which is extremely similar to <format> is lowered by the compiler in terms of the runtime's implementation of String.Format(...), which in turn defers to FormatHelper, which speculatively allocates <format string length> + <number of args> * 8.

Maybe it's worth finding out whether this is an informed guess, the result of analyzing the runtime behaviour of existing codebases, or just 🎩✨🐇 ¯_(ツ)_/¯

[AdamBucior]

Shouldn't the strings from the benchmark fit into the Small String Buffer and not need allocation at all?

They were wstrings which have half the Small String Buffer of string.

which speculatively allocates <format string length> + <number of args> * 8.

Taking number of args into account might also be a good idea. Maybe we could even filter string(_view) arguments from args and take their lengths into account.

[jovibor]

This is definitely related to the formatter string size.
When string is too long (avoiding SSO) the results for std::format become even worse, it's about two times slower than fmt.
The difference between wstring and string formatters is also significant, with the latter being faster.

Here the full test code with format_to and swprintf included.

[jovibor]

I'm still a bit concerned about performance. After all the recent changes, the difference is as follows:

The std::format_to is almost on pair with fmt::format_to.
While std::format is more than 3 times slower than its fmt counterpart.

Microsoft Visual Studio 16.10.0 Preview 2.1 /O2 /utf-8
std::format version: 02ae70a

[sylveon]

Can you share your benchmark code?

[jovibor]

Can you share your benchmark code?

The link is one post above.

[sylveon]

Thanks, after looking at it through a profiler, we are spending an absurd amount of time in _Fmt_iterator_buffer<back_insert_iterator<wstring>>::_Grow. If I replace the format_to benchmark to use a back_insert_iterator, I am seeing a similar amounts of time.