Not for a release builds though. Moreover, in general Windows compilation is always slower than on Linux, they should improve their OS FS IO performance.
This is in part because of how Windows Defender works. It scans created binaries, blocking them whilst doing so and interferes with compilation. This is the reason there often exists a hidden Windows Defender exception folder for developers. I have seen IT of 2 different companies setting this up now and there really is a time difference.
Whilst not quite on topic, this is especially catastrophic for anything that uses fork() and friends via Cygwin. (i.e. the MSYS2 ecosystem and the MinGW64 compiler suite). MSYS2 native `git add -> [tab]` halts the freezes command line for a second and turning off Windows Defender or using folder exceptions easily cuts compilation time by for Makefiles with multiple small files 30%.
Note that while Windows small file IO is slow; it's extra-slow on C:.
I have two partitions (C: and D:) on the same SSD, and creating a whole bunch of empty files (1.txt to 10000.txt) runs 2x faster on D: than it does on C:.
I believe there's two reasons for this:
* C: has extra IO filter drivers for system integrity that eat up CPU
* C:, by default, enables 8dot3names for compatibility (e.g. with software that expects C:\Progra~1\ to work as an alias to C:\Program Files\). On other partitions, 8dot3names are disabled by default.
So I recommend putting the OS on a separate partition from all development activities. Also, don't forget to exclude D: from Windows Defender.
This was measuring a full build, but in the real world what matters most is incremental builds.. where MSVC performs very well since it has incremental linking & compiling.
Also who even knows what this build was doing as it used CMake(garbage). It isn't clear what compiler settings were enabled either since again CMake.
That's surprising. I haven't used MSVC in almost a decade, but I remember being significantly slower to compile than both GCC and clang. Did it improve since?
That's surprising. I haven't used MSVC 6 in over two decades, but I remember gcc2.95 (redhat patch was 2.96) being significantly slower and clang didn't even exist. But we had pretty cool trance music at the time.
> Did you read the article? MSVC compiles twice as fast as clang and has double the perf in debug builds.
To me that means absolutely nothing, as visual studio and msbuild fails to support basic features like compiler launchers, which enable using compiler cache tools like ccache or sscache.
While you're benchmarking compilers, I plug ccache and build projects with dozen of subpackages in under a minute with build servers maxing out on IO.
LLVM has an amazing optimizer but the compiler is just so much slower even on unoptimized builds.