@vitaut

compile time and binary size of the stdlib implementations of format and print.

watch the video.. it's only 7mins

@vitaut

yes, I am aware.

I just thought Jason covering it, would be good opportunity to broaden awareness of the real cause of the issue (QoI) and that we can hopefully expect improvements.

stdlibc++ needs to follow suit...
waiting for MSVC might take a long time.

@oschonrock @vitaut

C'mon Oliver, you can do better and check the facts first:

https://godbolt.org/z/aszhcjcPe

@DanielaKEngert @vitaut

OK Dani, I stand corrected. 🫡

Bloat is gone. How is the speed?
CE link was cached, and not sure how to turn it off.

So does @vitaut 's theory apply?

Will the other Vendors be shamed into fixing their QoI?

@oschonrock @vitaut
@lefticus

Simply change the source a bit, e.g. like so:

https://godbolt.org/z/M944r3z19

Tested right now (twice):
MSVC came back after 1-2 seconds,
Clang after 2-3 seconds,
GCC took forever.

@DanielaKEngert @vitaut @lefticus

I got similar proportions, but twice as slow for all..

then I tried std::cout <<

clang & MSVC were fastest, about 40% faster than MSVC was on std::print. GCC's std::cout speed was comparable to MSVC's std::print...

But clearly CE is not a repeatable platform for these sorts of tests, nor is this "sample of one" methodology any good.

@DanielaKEngert would you say MSVC std::print speed approaches std::cout?

@oschonrock @vitaut @lefticus

Testing speed in CE is more or less futile unless you want to get a first ballpark impression.

Regarding your std::print vs. std::cout question: what is your objective?

- compile throughput?
- runtime performance?
- something else?

In our codebase, not throwing because of stooopid errors is paramount. We switched to fmt::format about a decade ago, and moved on to std::format during the VS2019 time frame - without any regrets due to noticeable build time increases.