我在C ++中有一个简单的单项目解决方案。在IDE中，我单击Build Solution，在发生任何事情之前需要40秒。然后17秒实际进行编译和链接。如果我再次单击Build Solution，则会有另外40秒的延迟。 devenv.exe正在忙于某事，因为它在此期间使用了我总CPU的13％。
如果我直接调用msbuild，它会立即启动。它不会重新编译，除非它真的过时了。所以它似乎根本不是msbuild的问题。
我已经谷歌搜索并追查了很多文章，但大多数人都在谈论为什么msbuild缓慢或失败，而不是为什么IDE调用msbuild的速度很慢。我甚至使用msbuild设置了外部工具，它立即启动。顺便说一句，该工具基于此：
http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx
我使用devenv.exe.config更改检查了丢失的文件，并且执行获取以下项目：
devenv.exe Information: 0 :
Project 'C:\Users\...\XFPMon\XFPMon.vcxproj' not up to date because 2 build outputs were missing.
devenv.exe Information: 0 :
up to date is missing: 'C:\WINDOWS\TEMP\AEXAM\AEX7C29.TMP'
devenv.exe Information: 0 :
up to date is missing: 'C:\WINDOWS\TEMP\AEXAM\AEX7C28.TMP'
对devenv.exe.config的更改是插入这些：
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
然后使用DbgView在构建期间跟踪输出。我无法想象为什么devenv.exe会认为TEMP文件会在构建之间保存。
我甚至删除了Debug和Release目录并从头开始编译。仍然是40秒的延迟。
如果我做了重建解决方案，则再延迟40秒。
但如果我做一个清洁解决方案，它会立即运行！
是否有人知道造成延误的原因是什么？
谢谢！
编辑： 更多的信息。我有8个内核，12 GB RAM和256 GB SSD，所以这台小机器具有原始马力。
当devenv.exe处于40秒延迟期间时，它总共占用了13％的CPU。编译开始时，它降至不到1％。内存使用量变化很小。它起始于458.2MB，在40秒延迟期间上升到459.9MB，然后在编译（如果有的话）结束后立即跳到463.1MB。
答案 0 :(得分：2)
好吧，我发现了问题。 Addin正在以指数时间处理.rc和.rc2文件。 Addin是在几个月前发布的，并且直到.rc文件的大小增长到足以导致（设计不当的）正则表达式运行得非常缓慢时才开始显示此问题。
更糟糕的是，我写了Addin！并且已经在几台机器上使用它大约一年没有问题。以前版本的Addin使用PCRE正则表达式用C ++编写，从未出现过问题（即使使用5年后）。但这是使用C＃和.NET Regex的重写，显然行为不同。
我通过重写代码来解决问题，以避免需要一些回溯。这很简单，但是对C＃Regex来说是必要的。
发现问题的关键是使用/ resetaddin选项启动devenv.exe。有了这个，构建立即开始。然后，只需要弄清楚哪个插件。我刚刚没有这样做，因为我几个月没有改变插件。
当.rc文件小到12K时出现此问题。我已经在262K .rc文件上测试了新版本，它运行时间为123毫秒。
叹息。