MaxEW707 wrote: > I would like some measurements so we can compare build times on Windows.
I took some benchmarks with `-ftime-trace` on the parse times with and without this change. Pretty much all the big hitters, string/vector/map/algorithm, includes `<xmemory>` which includes `<limits>` which includes `<intrin[0].h>`. The test file used looked as follows to simulate some common stl includes. ``` #include <map> #include <vector> #include <memory> ``` clang-cl 16 frontend took ~190ms to parse those 3 headers. `intrin.h` took ~32ms to parse. clang-cl built with this PR frontend took ~1368ms to parse. `intrin.h` took ~969ms to parse. Most of that time is from `<x86intrin.h>` as expected. `intrin0.h` took ~2ms to parse. It is known that `immintrin.h` and `x86intrin.h` being the everything header definitely makes it an **expensive** include. I don't need to compile any project to know that include time difference will be felt by any code that uses STL. MSVC STL ships with each compiler upgrade. VS has a separate dir for each installed msvc, `VC\Tools\MSVC\14.38.33130` for MSVC 1938, and each installed compiler has a specific version of msvc stl shipped with it under, `VC\Tools\MSVC\[version]\include`. Only one version of clang-cl is shipped with VS at a time and it will always point to the latest `VCToolsDir` via the clang driver unless clang is passed an explicit dir on the command line by the user. For example VS2022 17.7 upgraded from clang-cl 15 to clang-cl 16. From that point on-wards only clang-cl 16 exists on disk in your VS install. That seems to correspond to what was said here, https://github.com/microsoft/STL/pull/4282#discussion_r1441191186, every shipped version of MSVC STL supports only the latest compilers provided by VS. We have some options. I am fine with whatever the consensus is as long as I can move this over the finish line. 1. Users who upgrade clang-cl before MSVC STL officially supports the new version of clang-cl will suffer slower builds. I would classify this as an unsupported config since once VS ships with support for the new clang-cl, intentionally building against an older `VCToolsDir` will also incur the include overhead. Up to you guys if view this as an unsupported config. 2. Add a config define that users can define to enable the old behaviour in the interim. Once MSVC STL supports the new version of clang-cl we can remove this config define in the next release. 3. Release clang with `intrin0.h`. Get a change into MSVC STL. Wait for MSVC STL release. Release another clang with `intrin.h` changes. I am not well versed on what changes clang allows in patch or minor releases but this feels like it would have a long lag time before clang-cl can become usable for us. https://github.com/llvm/llvm-project/pull/75711 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
