非常慢的VS2017 C++；链接器速度 我们将我们的C++项目从VS2013升级到VS2017。但在VS2017中，调试构建的链接时间也非常糟糕。有了这样的价值观，就不可能进行有效的开发

当我在项目中更改单个文件时，在VS2013中需要2.6秒。当我在VS2017中对同一文件执行相同操作时，需要30秒

VS2013
1>       32 ms  ComputeCLOutputs                           1 calls
1>      199 ms  WarnCompileDuplicatedFilename              1 calls
1>     2688 ms  Link                                       1 calls
1>     4073 ms  ClCompile                                  1 calls

VS2017
1>       31 ms  ComputeCLOutputs                           1 calls
1>       44 ms  CustomBuild                                1 calls
1>      239 ms  WarnCompileDuplicatedFilename              1 calls
1>     8021 ms  ClCompile                                  1 calls
1>    29725 ms  Link                                       1 calls

这比VS2013慢了15倍多

目前，我的电脑上安装了两个Visual Studio，因此我可以同时对其进行测试。我尝试了很多和谷歌搜索一样的东西，但都没有成功

我试过：

• 在VS2017中编译相同的项目，但使用VS2013工具集和链接需要2.6秒。因此，问题在于VS2017中的工具集，而不是VS2017 IDE

• 我尝试了许多与DebugInformationFormat的组合，如/Zi和/Z7，以及/DEBUG vs/DEBUG:Fastlink、/INCREMENTAL、，。。。但任何其他设置都比QMake生成的默认设置更糟糕（/Zi+/DEBUG:Fastlink+/INCREMENTAL）

• 我还尝试了与32/64位目标相同的32位和64位编译器/链接器。但这对性能没有任何影响

• 我尝试将VS2013项目转换为VS2017，与通过Qt Qmake生成新项目一样，但也没有任何区别

在链接期间，CPU的使用率不为100%，正如SSD驱动器的使用率不为100%。我试图输出详细的链接日志，但并没有什么特别之处（并没有外来的临时文件，等等，就像其他答案中提到的）

这是完整的编译器命令行

/Yu"stdafx.h" /MP /GS /analyze- /W3 /wd"4577" /wd"4467" /Zc:wchar_t /I ...INCLUDE FOLDERS... /Zi /Gm- /Od /Fd"objs\Debug32\" /FI"stdafx.h" /fp:precise 
/D "_WINDOWS" /D "UNICODE" /D "WIN32" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /MDd /Fa"objs\Debug32\" /EHsc /nologo /Fo"objs\Debug32\" 
/Fp"Debug32\\App.pch" /diagnostics:classic 

-Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zm130 -w44996 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 

和链接器命令行

/OUT:"Debug32\\App.exe" /MANIFEST /NXCOMPAT /PDB:"Debug32\App.pdb" /DYNAMICBASE "Q:\SharedLibraries2017\Qt32\lib\qtmaind.lib" "shell32.lib" ...
 /VERSION:"1.0" /DEBUG /MACHINE:X86 /SAFESEH /INCREMENTAL /PGD:"Debug32\App.pgd" /SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'" 
 /ManifestFile:"_App\objs\Debug32\App.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"Q:\SharedLibraries2017\Qt32\lib" /TLBID:1 

"/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" 

我发现很少有关于慢速链接的帖子，但对我没有任何帮助（64位，擦除临时文件，启动同步/资源控制/代码镜头/诊断，在新文件夹中清理构建…）

我使用的是最新的VS2017版本15.5.6，工具集v141，SDK 10.0.16299.0

任何帮助都将不胜感激

增加：

我的电脑设置为： i7-7700K CPU@4.2Ghz 16GB内存 固态硬盘驱动器 最新Win10

编辑：

我尝试了另一个（较小的）项目

当我完成重建时，我得到了以下结果：

VS2013:
1>     2898 ms  Link                                       1 calls
1>    11987 ms  CustomBuild                                1 calls
1>    68238 ms  ClCompile                                  1 calls

VS2017
1>     2822 ms  Link                                       1 calls
1>    14221 ms  CustomBuild                                1 calls
1>    67243 ms  ClCompile                                  1 calls

所以几乎相同的结果。但是，当我在这两个项目中更改例如main.cpp并进行编译+链接时，我得到了以下结果：

VS2013:
1>      577 ms  Link                                       1 calls
1>     1261 ms  ClCompile                                  1 calls

VS2017
1>     1196 ms  ClCompile                                  1 calls
1>     3145 ms  Link                                       1 calls

所以，问题似乎在于，无论有多少个文件链接在一起，在VS2017中，时间都是一样的

编辑2：

基于@seccur idea，我还安装了VS2015工具包

同样，两个相同的项目，都是完全编译和链接的，并且都在我修改过的main.cpp文件中

VS2015 (2015 v140)
1>       64 ms  WarnCompileDuplicatedFilename              1 calls
1>      594 ms  Link                                       1 calls
1>     1312 ms  ClCompile                                  1 calls

VS2017 (2017 v141)
1>       43 ms  WarnCompileDuplicatedFilename              1 calls
1>      754 ms  ClCompile                                  1 calls
1>     2082 ms  Link                                       1 calls

---

两个项目都是在VS2017 IDE中打开的，都具有相同的设置，唯一的区别是工具包选择。很明显，v141工具包完全存在漏洞。

尽管相比之下这是一个很差的问题，我不是说这里没有问题，也不是说你不应该尝试修复它。。。它真的“阻止有效发展”吗？大型项目的建设时间比这要长得多。我愿意用我的左腿做30秒的建造时间！也许您在工作周期中重建得太频繁了？这不是整个项目的构建时间。当一个文件在整个项目中被更改时，它是构建时间+链接时间-所以我们只讨论链接阶段-这更合理一些。不过，我还是不太明白。更改文件后，无论如何都必须将所有内容重新链接到新的可执行文件中。为什么你更改了多少文件会很重要？或者这确实是问题所在？请检查问题底部添加的示例。当我在VS2013中更改一个文件时，链接阶段需要500ms，在VS2017中，链接阶段需要3000ms，无论我是否重新编译整个项目，或者如果我只再次更改一个文件，链接阶段必须完成的工作并不取决于在此之前重新编译了多少文件。除非MSV（我承认我对它不是很熟悉）有一些非凡的缓存魔法。你是说当你重新编译一个文件时，构建过程比重建整个项目时要长吗？