Re-implement built-in conversions using `std::format_to_n()` / `std::formatted_size()`?

[jtv]

It looks to me like we could easily replace most conversions from built-in arithmetic types to strings with std::format_to_n() and the corresponding budgeting with std::formatted_size().

Benefits:

• Less dichotomy between integral and floating-point types.
• Ditch complex buffer-budgeting code.
• Trust standard library optimisations over custom cleverness.
• Just maybe get rid of the horrible workarounds for missing floating-point charconv support.

In all honesty, I was quite proud of my trick of writing integer conversions back-to-front in to_buf() and just not caring whether the string would start at the beginning of the buffer. But it's doubtful that I'd be getting much better performance than a good standard-library implementation.

Risks/costs:

• Need to figure out levels of floating-point support from scratch.
• Feels wasteful to have the library parse "{}" format strings every time.
• Missing out on constexpr.

[tt4g]

Missing out on constexpr.

At least at compile time, std::basic_format_string<T> appears to be a compile-time constant in order to parse the format string: https://en.cppreference.com/w/cpp/utility/format/basic_format_string.html

However, since format arguments support runtime values, it can be assumed that the length after formatting is not determined at compile time.

[jtv]

Ah @tt4g I guess that means there will be no run-time repeated parsing of the format string? That's a comfort.

[tt4g]

Yes. std::basic_format_string<T> is always evaluated as a compile-time constant.
And we have a constraint that we cannot construct format strings at runtime without explicitly using std::runtime_format() (supported since C++26).

But unfortunately, formatting isn't done at compile time.
This may be unavoidable, considering that the std::format API supports user-defined type formatting (via std::formatter) and therefore can only be formatted at runtime.

[jtv]

Oh this is disappointing. I thought standard library implementations would be incredibly well-optimised and this would outweigh the costs of the genericity that I don't need.

But a quick first benchmark shows that libpqxx's int-to-string conversion is considerably faster than the format library. I'll need to do a bit more testing, and probably use the format library only selectively.

[jtv]

Using gcc 13 with -O2 I compared...

• pqxx::to_string() on an int vs. std::format() on an int.
• pqxx::to_string() on a double vs. std::format() on a double.
• pqxx::to_buf() and pqxx::into_buf() on an int vs. std::format_to_n() on an int.
• pqxx::to_buf() and pqxx::into_buf() on a double vs. std::format_to_n() on a double.

The results surprised me. In all cases, the libpqxx solutions were faster. Never more than twice as fast, but it wasn't ever insignificant either. (As you'd expect, pqxx::to_buf() was also slightly faster than pqxx::into_buf() but not by a lot.)

It's not unbelievable that the libpqxx routines were faster, since they have a few built-in advantages:

• They don't support a wealth of formats and options.
• The design can be less generic.
• In the case of integers, pqxx::to_buf() gets extra freedom to place the result where it wants, and there's an optimisation where it works backwards from the least significant digit.

Still, I kind of expected the concentrated optimisation work in standard library implementations to outweigh those advantages. It didn't, at least not with my compiler.

The floating-point conversions boiled down to a race between std::to_chars() and std::format_to_n(), so I expected the numbers to even out there. I can only guess... Could be the parsing of the format string (even though in theory that can be done at compile time), or libpqxx's aggressive pre-allocation of space inside the string.

Anyway, my conclusion is: for now I should try to keep my existing conversion code where possible, but in the workaround case for missing floating-point charconv, use the formatting library instead of the streams library if compiler support is satisfactory.

Next step: survey compiler support.

[jtv]

I've just made a change to the 8.x string conversion API where converting a value to a string no longer requires zero termination. In the long run, that will make the libpqxx routines slightly faster yet (and also require slightly less buffer space).

[SapiensAnatis]

I have written a converter for std::chrono::time_point<std::chrono::system_clock> using format_to_n and it was quite simple in the end. That said, I haven't put it through its paces in production yet so I'm not sure how performant or reliable it is. Would there be any interest in upstreaming this?

[jtv]

@SapiensAnatis I kind of wanted that, but I ended up not bothering for the one really silly reason that it didn't make it any easier to write the conversations for full dates.

I started off naïvely thinking that to convert a date, I could start by converting the year. But if the year is negative, that puts the "BC" in the wrong place!

Anyway in libpqxx 7.x I can't use the formatting library because it has to work in C++17, but we can use it in libpqxx 8.

[jtv]

@SapiensAnatis I'm now also simplifying the string conversion API a bit, so you no longer need to implement into_buf(), just to_buf(). Also, the trailing zero is no longer going to be there — output is going to be simply a std::string_view.

[jtv]

I guess the one place where the formatting library would be useful in conversions is in working around missing floating-point charconv conversions in compilers.

I don't know if that's still a relevant issue, but it'd be nice to be rid of my ugly old workarounds for those compilers. Just seems weird to replace an ugly old workaround for incomplete C++20 compilers with a more modern workaround that relies on C++20 features. I mean, a compiler would have to support the one feature but not the other for this to be useful.