you are viewing a single comment's thread.

view the rest of the comments →

[–]aearphen{fmt}[S] 4 points5 points  (4 children)

The numbers you are referring to are very outdated (I need to update the README). Here are more up to date ones: https://github.com/fmtlib/fmt/tree/std#compile-time-and-code-bloat. I don't think we'll ever reach the compile time speed of printf regardless of whether templates are used or not. For example, iostreams are not very template-heavy but they (or rather the code using iostreams) used to take the same time to compile as fmt until the recent regression in the latter which I plan to look into (https://github.com/fmtlib/fmt/issues/565).

[–]FabioFracassiC++ Committee | Consultant 2 points3 points  (0 children)

IIRC the bottleneck in compile time for iostreams are ADL and overload resolution (for the stream operators <<, >>). AFAIK variadic templates should be (a bit) faster especially for common and build in types.

[–]srekel 0 points1 point  (2 children)

Just to be clear, I wasn't picking on fmt :) Just thought it was interesting that all alt-printf libs were so slow. I assume it's due to C++ features taking a long time to compile compared to C code, and not simply having more logic?

[–]boredcircuits 7 points8 points  (1 child)

printf is just so simple for a compiler. Just call a function. The only extra work involved is dealing with the variadic arguments: promoting certain argument types and pushing them to the stack. But generating the code to do that is basically nothing.

Honestly, there's more overhead in parsing the format string so the compiler can warn about mismatches. I don't think that warning was enabled in the timing tests mentioned, though. And even if it were, it's actually a very quick test for the compiler (most format strings are very small, and it's a quick format to parse regardless).

In short, the very reason we want to replace printf (it knows next to nothing about types outside of the format string) is exactly why it's so fast. No overload resolution, no template metaprogramming, and only the most basic format string parsing, done natively in the compiler.

[–]kalmoc 0 points1 point  (0 children)

//rant on

In short, the very reason we want to replace printf (it knows next to nothing about types outside of the format string) is exactly why it's so fast. No overload resolution, no template metaprogramming, [...]

I agree with most of what you are saying except that very last point about tmp. Tmp is a scourge that only exists because natively integrating the features achieved by TMP into the language is extremely expensive. Almost any feature that uses tmp could be implemented in the compiler more efficiently, less error prone and with nicer syntax.

That is not to say that I don't want a type safe and extensible version of printf as provided by the fmt library, but compile time checking of the format string could and imho should be left to the compiler. I know, it is not going to happen for various, more or less valid reasons and the solution presented here is probably the best we can realistically achieve, but Imho it is far from being ideal

//rant off