Proposal: prepared statements

[gabime]

While #613 would be great, but will probably only supported for c++17.

Another approach would be to have kind of prepared templates (or prepared statements - a bit like in db, but fmt need not to store or manage the handle anywhere - the handle itself would contain all the needed info).

The user would pass a format string he expects to use a lot and get a handle to a "compiled" version of the format string:

// fmt returns a handle object that can be executed like this:
auto handle = fmt::prepare("My name is {}. I am {} years old."); 


// and then the user can make heavy use of it
auto result = handle->format(arg1, arg2);
// or maybe
auto result = fmt::format(handle, arg1, arg2);

The handle would contain an efficient representation of the format - list of actual formatters to use, their flags, and their offsets in the format string.
I am not sure if the result would be much faster for simple format strings, but complex format strings, it might give big performance boost.

[vitaut]

Thanks for the suggestion. It sounds very similar to what Bengt Gustafsson's proposed in https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/4wOU-1_3D0A/xiNQSmO1CAAJ:

I think it may make sense to allow pre-creating a formatting object for an entire format string, so that the parsing of that string occurs only once.

and, in fact, I've already done most of the work to make this possible, namely separated parsing and formatting as part of compile-time format string parsing support. It still needs to be packaged in an API similar to the one you proposed with the main difference that prepare function or its equivalent should take argument types in addition to format string:

auto formatter = fmt::prepare<std::string, int>("My name is {}. I am {} years old.");

[vitaut]

BTW #613 can work with C++14.

[gabime]

Do you think adding this feature, or will you do #613 first ?

[vitaut]

Not sure, #613 will give much better runtime performance but, as you noticed, it will require a modern compiler. This one is a small optimization, mostly for the case when you need to process the same format string multiple times. My main focus right now is addressing standards proposal feedback (#518), but I'll get back to this idea afterwards.

[stryku]

Hello, does this proposal need to wait for some other dependency than #581, or I can fool around a little and try to implement this? Or you want to postpone it?

[vitaut]

No this doesn't have to wait on anything.

I can fool around a little and try to implement this?

Please do. Contributions are always welcome!

[stryku]

I think I've finished implementation for this (at least for the first review). Now I'm checking whether my changes are compilable by all of the supported compilers and I have one question. Against which compilers should I check my code? In the Portability section, GCC 4.4, Clang 2.9 and MSVC 18.0 (2013) are listed but in the travis script there is a clang 4.0, not 2.9. So which one should I test?

[vitaut]

Testing the ones listed in the Travis CI config should be fine, particularly GCC 4.4 which is the oldest.

[ton]

Is fmt::prepare a thing? I would like to have something like that. Maybe some other functionality made it obsolete?

[vitaut]

It has been renamed to fmt::compile.

[simonhf]

Is fmt::compile similar to the idea presented here [1] back in February 2016 where "compiling" avoids "reparsing"?

Is there any info regarding possible performance gains to be had with fmt::compile?

[1] #269

[vitaut]

Yes, although it has been superseded by FMT_COMPILE: https://fmt.dev/latest/api.html#compile-api. Performance gains depend on the actual arguments, some results for integers are available here: http://www.zverovich.net/2020/06/13/fast-int-to-string-revisited.html.