Did you build in WSL from its native file system or from the Windows one? WSL access to the Windows file system is notoriously slow, so it may be better to make a copy of the project in the WSL file system to measure the build speed. Thanks.
Have you excluded your Windows source and build directories from antivirus scanning? In my experience that’s the most common reason for slow builds on Windows.
I think it worth to report such performance gap between clang-cl and native msvc cl for the release mode at least with minimal reproduce code. https://developercommunity.visualstudio.com/cpp
I think I provide enough information for reproduction in my blog post. I already formally reported that Visual Studio has non-competitive performance with SIMD kernels like simdutf.
Patrick Stewartsays:
If you’re using a recentish version of LLVM and CMake on windows, you don’t need to use the clang-cl driver at all. A trivial toolchain file for cmake like:
run in the VS development prompt will get it working with the normal clang frontend, so you can use the normal GCCish arguments.
If it’s linking that’s taking the time, adding the “-fuse-ld=lld” argument will speed it up a lot, as lld is much faster than link.exe.
A debug build then takes 2 minutes and slightly over 2 minutes for a release build.
Michael Walcottsays:
I don’t know if it applies here but one thing I’ve noticed in particular is that clang-cl tends to inline a lot more aggressively than MSVC.
Chrissays:
Note that with Visual Studio 2019+, you can use the /Ob3 flag for more aggressive inlining.
/Ob2 is the default when using /O2
I haven’t tested if this actually makes a difference though.
Thanks for catching the typographical error. I did use lld.
Andreassays:
Process creation on Windows is really expensive. It was bad enough for the chrome build that they finally changed the clang driver to call its internal drivers directly in-process instead of in a new process.
And file system operations are slow for many small files. Someone said that’s only because of hooks like antivirus but it still feels like ntfs is slower in general then ext4.
Cloud servers may have ramdisk mounted for tmp.
https://m.youtube.com/watch?v=t4M3yG1dWho
Intriguing.
Did you build in WSL from its native file system or from the Windows one? WSL access to the Windows file system is notoriously slow, so it may be better to make a copy of the project in the WSL file system to measure the build speed. Thanks.
I did not make a copy.
Blog post updated.
Have you excluded your Windows source and build directories from antivirus scanning? In my experience that’s the most common reason for slow builds on Windows.
I disabled Defender temporarily and it did not impact the speed, at least not in a noticeable manner for me.
Might be related: https://dev.blog.documentfoundation.org/2023/02/21/telemetry-required-ask-users-first/
I am not getting build errors.
Sure, but the point was that there’s telemetry in the build process thst many don’t expect, and that that might be related to slower builds.
Could be.
I think it worth to report such performance gap between clang-cl and native msvc cl for the release mode at least with minimal reproduce code.
https://developercommunity.visualstudio.com/cpp
I think I provide enough information for reproduction in my blog post. I already formally reported that Visual Studio has non-competitive performance with SIMD kernels like simdutf.
If you’re using a recentish version of LLVM and CMake on windows, you don’t need to use the clang-cl driver at all. A trivial toolchain file for cmake like:
set(CMAKE_C_COMPILER clang)
set(CMAKE_CXX_COMPILER clang++)
set(CMAKE_RC_COMPILER llvm-rc)
run in the VS development prompt will get it working with the normal clang frontend, so you can use the normal GCCish arguments.
If it’s linking that’s taking the time, adding the “-fuse-ld=lld” argument will speed it up a lot, as lld is much faster than link.exe.
That’s useful.
I tried the following…
cmake -D CMAKE_LINKER=”ldd” -D CMAKE_CXX_COMPILER=clang++ -D CMAKE_RC_COMPILER=llvm-rc -B buildfastclang3
A debug build then takes 2 minutes and slightly over 2 minutes for a release build.
I don’t know if it applies here but one thing I’ve noticed in particular is that clang-cl tends to inline a lot more aggressively than MSVC.
Note that with Visual Studio 2019+, you can use the /Ob3 flag for more aggressive inlining.
/Ob2 is the default when using /O2
I haven’t tested if this actually makes a difference though.
I have found that Ob3 did not make a difference in a project of mine: https://github.com/simdjson/simdjson/issues/847
Note that you can give compiler hints to Visual Studio, telling it to inline a function. I think it works.
The linker is lld, ldd prints dependencies for dynamic executables.
Thanks for catching the typographical error. I did use lld.
Process creation on Windows is really expensive. It was bad enough for the chrome build that they finally changed the clang driver to call its internal drivers directly in-process instead of in a new process.
And file system operations are slow for many small files. Someone said that’s only because of hooks like antivirus but it still feels like ntfs is slower in general then ext4.