`<format>`: `inline` overloads of `vformat()` are costly for throughput

[StephanTLavavej]

@xiangfan-ms reported (slightly edited for Markdown):

<format> contains 4 overloads of vformat. They will specialize lots of other templates. But unlike other functions in STL headers, they are non-template.

STL/stl/inc/format

Lines 2885 to 2911 in 178b840

	_NODISCARD inline string vformat(const string_view _Fmt, const format_args _Args) {
	string _Str;
	_Str.reserve(_Fmt.size() + _Args._Estimate_required_capacity());
	_STD vformat_to(back_insert_iterator{_Str}, _Fmt, _Args);
	return _Str;
	}
	_NODISCARD inline wstring vformat(const wstring_view _Fmt, const wformat_args _Args) {
	wstring _Str;
	_Str.reserve(_Fmt.size() + _Args._Estimate_required_capacity());
	_STD vformat_to(back_insert_iterator{_Str}, _Fmt, _Args);
	return _Str;
	}
	_NODISCARD inline string vformat(const locale& _Loc, const string_view _Fmt, const format_args _Args) {
	string _Str;
	_Str.reserve(_Fmt.size() + _Args._Estimate_required_capacity());
	_STD vformat_to(back_insert_iterator{_Str}, _Loc, _Fmt, _Args);
	return _Str;
	}
	_NODISCARD inline wstring vformat(const locale& _Loc, const wstring_view _Fmt, const wformat_args _Args) {
	wstring _Str;
	_Str.reserve(_Fmt.size() + _Args._Estimate_required_capacity());
	_STD vformat_to(back_insert_iterator{_Str}, _Loc, _Fmt, _Args);
	return _Str;
	}

It takes 0.83s to compile <format> and all its dependencies. But if I remove the definition of vformat, it only takes 0.62s.

Here are some data:

	With definition	Without definition
Overload resolution	0.185821s / 11218	0.075068s / 6024
Instantiate template specialization	0.161868s / 1333	0.079736s / 583
Specialize template	0.187945s / 10900	0.091789s / 7597
Parse default template argument	0.008578s / 691	0.004705s / 403

I believe that template <int = 0> should be sufficient to delay this throughput cost (i.e. unless and until vformat() is actually called), and that it should be unobservable because users are now forbidden from taking the addresses of Standard Library functions. We should probably have comments as to why we're doing this.

@xiangfan-ms replied:

The template <int = 0> trick seems to work (two phase will still try to bind the function call to std::vformat_to, but I think the function specialization isn't added to the list to be instantiated).

[TymianekPL]

I assume all the *_impl functions are not templates (but rather inlined definitions) because they are solely meant to be used by templated entities (such as println)?

[TymianekPL]

but then again similar(or same) entities are marked as template <int = 0> in <ostream> (such as _Vprint_nonunicode_impl function template in ostream [with _Vprint_nonunicode_impl function in <print>)

[TymianekPL]

// <print>
// Format non unicode directly into _Stream
inline void _Vprint_nonunicode_impl(
    const _Add_newline _Add_nl, FILE* const _Stream, const string_view _Fmt_str, const format_args _Fmt_args) {
    const _Stream_lock_guard _Guard{_Stream};
    _STD vformat_to(_Print_to_stream_it{_Stream}, _Fmt_str, _Fmt_args);
    if (_Add_nl == _Add_newline::_Yes) {
        _Print_noformat_nonunicode_nonlocking(_Stream, "\n");
    }
}

// <ostream>
template <int = 0>
void _Vprint_nonunicode_impl(
    const _Add_newline _Add_nl, ostream& _Ostr, const string_view _Fmt_str, const format_args _Fmt_args) {
    const ostream::sentry _Ok(_Ostr);
    ios_base::iostate _State = ios_base::goodbit;

    if (!_Ok) {
        _State |= ios_base::badbit;
    } else {
        // This is intentionally kept outside of the try/catch block in _Print_noformat_nonunicode()
        // (see N4950 [ostream.formatted.print]/3.2).
        string _Output_str = _STD vformat(_Ostr.getloc(), _Fmt_str, _Fmt_args);
        if (_Add_nl == _Add_newline::_Yes) {
            _Output_str.push_back('\n');
        }

        _State |= _STD _Print_noformat_nonunicode(_Ostr, _Output_str);
    }

    _Ostr.setstate(_State);
}

yeah they are different. One takes FILE* and the other ostream&