"I can recompile the entire thing from scratch in ~4.3s. That’s around ~900 TUs, including external dependencies, tests, and examples"
In 30 years of using C++ this is the first time I've ever come across "translation unit" being abbreviated to TU and it took a bit of effort to figure out what the author was trying to say. Not sure why they felt the need to abbreviate this when they explain PCH for instance, which is a far more commonly used term.
Thought I'd add the context here to help anyone else out.
show comments
leni536
libstdc++'s <print> is very heavy, reflection or not. AFAIK there is no inherent reason for it to be that heavy, fmtlib compiles faster.
<meta> is another question, it depends on string_view, vector, and possibly other parts. Maybe it's possible to make it leaner with more selective internal deps.
show comments
r2vcap
Yuck. I’ve already noticed compilation times increasing from C++17 to C++20, and this feature makes it much worse. I guess I’ll need to audit any reflection usage in third-party dependencies.
wjakob
I am very worried by feature creep in libc++ and libstdc++ and the harm that this inflicts on the wider C++ ecosystem. Transitive inclusion of large parts of the STL, and entangling of STL with core language features are both extremely bad. This should IMO be topic #1 of the committee but is barely even noticed. The mantra "It's okay, modules will save us" is naive and will not work.
show comments
dalvrosa
Nice to learn about hyperfine
Compilation speed is a huge part of productivity and enjoying writing C++
SuperV1234
I ran some more measurements using import std; with a properly built module that includes reflection.
There are no zero cost abstractions: https://youtu.be/rHIkrotSwcc?si=oSBlKG9M_Ey8sVIU
"I can recompile the entire thing from scratch in ~4.3s. That’s around ~900 TUs, including external dependencies, tests, and examples"
In 30 years of using C++ this is the first time I've ever come across "translation unit" being abbreviated to TU and it took a bit of effort to figure out what the author was trying to say. Not sure why they felt the need to abbreviate this when they explain PCH for instance, which is a far more commonly used term.
Thought I'd add the context here to help anyone else out.
libstdc++'s <print> is very heavy, reflection or not. AFAIK there is no inherent reason for it to be that heavy, fmtlib compiles faster.
<meta> is another question, it depends on string_view, vector, and possibly other parts. Maybe it's possible to make it leaner with more selective internal deps.
Yuck. I’ve already noticed compilation times increasing from C++17 to C++20, and this feature makes it much worse. I guess I’ll need to audit any reflection usage in third-party dependencies.
I am very worried by feature creep in libc++ and libstdc++ and the harm that this inflicts on the wider C++ ecosystem. Transitive inclusion of large parts of the STL, and entangling of STL with core language features are both extremely bad. This should IMO be topic #1 of the committee but is barely even noticed. The mantra "It's okay, modules will save us" is naive and will not work.
Nice to learn about hyperfine
Compilation speed is a huge part of productivity and enjoying writing C++
I ran some more measurements using import std; with a properly built module that includes reflection.
I first created the module via:
And then benchmarked with: The only "include" was import std;, nothing else.These are the results:
- Basic struct reflection: 352.8 ms
- Barry's AoS -> SoA example: 1.077 s
Compare that with PCH:
- Basic struct reflection: 208.7 ms
- Barry's AoS -> SoA example: 1.261 s
So PCH actually wins for just <meta>, and modules are not that much better than PCH for the larger example. Very disappointing.
The hidden compile-time cost of <insert almost any C++ feature>
How is it hidden if you can measure it?