<format>: Avoid unnecessary calls to _Getcvt()

[statementreply]

The performance of format degraded after #1815. Profiling shows that _Getcvt() is consuming a significant part of the CPU time.

We could investigate:

• Avoid calling _Getcvt() when unnecessary (when the format string is interpreted as UTF-8 or UTF-16).
• Reduce the number of calls to _Getcvt().

#include <chrono>
#include <format>
#include <iostream>
#include <iterator>
#include <ratio>

using namespace std;
using namespace std::chrono;

int main() {
    constexpr int iters = 10'000'000;

    string buf;
    buf.reserve(64);
    size_t dummy = 0;

    const auto start_time = steady_clock::now();

    for (int i = 0; i < iters; ++i) {
        buf.clear();
        format_to(back_inserter(buf), "run {0}/{1}", i + 1, iters);
        dummy += buf.size();
    }

    const auto end_time     = steady_clock::now();
    const auto average_time = duration<double, nano>{end_time - start_time} / iters;

    cout << "average time: " << average_time << "\n";
    cout << format("dummy: {}\n", dummy);
}

cl /EHsc /W4 /WX /std:c++latest /O2 /utf-8 temp.cpp

Before #1815: 179 ns
After #1815: 241 ns

[barcharcraz]

#1834 should have fixed this issue, I'm confirming now.

[CaseyCarter]

#1834 should have fixed this issue, I'm confirming now.

After #1834 we no longer call __std_get_cvt (which is basically a reimplementation of _Getcvt that takes a code page number as an argument) at all when formatting wide strings or when formatting narrow strings if the execution character set is UTF-8.

We could still probably do a bit better for other cases by caching the result of __std_get_cvt at a higher level to reduce the total number of calls. My attempts to do so in the initial implementation were foiled by needing the info both while parsing format strings and while formatting; there was no good central place to cache and too little time for large-scale restructuring.

[barcharcraz]

that's after #1834, and I've confirmed in benchmarks that no calls to locale getting functions occur (it was a sampling benchmark, but with how long those calls take I don't think that's a problem)

[MikeGitb]

Any idea what causes the 3x perf differencein back_insert_to_string?