The other day: “hmm building blender got quite a bit slower” (by 10-15%). What caused it? Of course, enabling “plz C++20” instead of previous “plz C++17” compiler option. This is without actually *using* any of 20 features yet.

😭

https://projects.blender.org/LazyDodo/BuildBench

@aras This is a big and common thing with C++20.

A bunch of things become constexpr and inline in C++20 is my memory, significantly increasing the cost of the standard library headers in _every_ compile. =[

@chandlerc yeah, plus I guess under 20 various headers become much larger (ranges & whatnot)
@aras @chandlerc What we (ALICE Experiment at CERN) see is actually an improvement in compile time for our stuff, whenever concepts are used over SFINAE or similar pre C++20 tricks. I would be interested in knowing if you experience the same, once / if you get to it.

@ktf @aras We've seen no meaningful improvements in compile time due to concepts TBH. Not that they're bad for compile times, but most of it doesn't go to extraneous instantiations in `enable_if` that concept checks avoid.

Much more from excessively slow/complex checking of inline function bodies in every translation unit.

@chandlerc @ktf @aras I dread to ask, but any data on whether modules help or hinder any of this?

@JSAMcFarlane @chandlerc @ktf @aras

Come to my talk at 'using std::c++' (Madrid, Spain) to learn about my measurements from a real production codebase.

@JSAMcFarlane @chandlerc @aras For us, it’s complicated. Getting everything ready for modules, including dependencies, it’s a nightmare. Moreover we do support Apple Clang.