aganea added a comment. In https://reviews.llvm.org/D52193#1239171, @hans wrote:
> Thanks for adding the Ninja numbers. It confirms that Ninja is significantly > faster than MSBuild + /MP. It is true for the 6-cores Xeon, but not for the dual-18-cores. I think there are two issues there, somehow unrelated to /MP: 1. Invoking the child clang-cl -cc1 for **each** cpp file makes things much slower. I’ve clocked the invocation at about 60-100ms (which is caused mainly by loading dlls & registery accesses). Most likely Reid’s change about delay loading dlls should improve that. 2. The other issue is, I think, the process context switching at the OS-level. This link: https://www.phoronix.com/scan.php?page=article&item=2990wx-linux-windows&num=4 - shows that multi-threading is significantly faster on a Linux machine, as far as high cores count goes (when compared with the same test ran on the same machine under Windows 10). > Since that's the case, maybe we should be poking MS about making MSBuild > faster instead of adding /MP support to Clang? Or making it easier to use > Ninja in VS projects? Your patch says RFC after all :-) Sad for Microsoft, but at this point it is a _design_ change MSBuild needs. And as a PM I would rather invest in bindings to better build systems (Ninja, Fastbuild). However I expect there are still users of MSBuild out there, and without /MP this means essentially that migrating to clang-cl requires also changing their build system and their VS2017 integration with the said build system. Repository: rC Clang https://reviews.llvm.org/D52193 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
