使用分布式编译。 Xoreax 不可思议可以将编译时间缩短到几分钟。

我在一个庞大的 C + + 解决方案中使用过它，通常需要5-6个小时来编译。IncrediBuild 帮助将这个时间缩短到了15分钟。

我最初在这里发布了这个回复: Https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 您可以在该页面上找到许多其他有用的提示。

如果使用 VisualStudio2008，则可以使用/MP 标志进行编译，以并行方式生成单个项目。我读到过，这也是 VisualStudio2005中的一个未记录的特性，但我自己从未尝试过。

您可以通过使用/M 标志并行构建多个项目，但这通常已经设置为机器上可用核的数量，尽管我相信这只适用于 VC + + 。

也许可以使用一些公共函数并创建一些库，这样就不会为多个项目反复编译相同的源代码。

如果您担心不同版本的 DLL 会混淆，请使用静态库。

如果这是 C 或 C + + ，并且您没有使用预编译头，那么您应该使用。

如果这是一个 Web 应用程序，将批量构建设置为真可以帮助取决于场景。

<compilation defaultLanguage="c#" debug="true" batch="true" >

你可以在这里找到一个概述: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

关闭 VSS 集成。您可能没有选择使用它，但是 DLL 总是被“意外地”重命名..。

并且一定要检查您的预编译头设置。布鲁斯道森的指南有点老，但仍然 非常好好检查一下: http://www.cygnus-software.com/papers/precompiledheaders.html

我有一个项目，其中有120或更多的前，库和 dll，并需要相当长的时间来建立。我使用从一个主批处理文件调用 make 文件的批处理文件树。在过去，我遇到过增量式(或者是喜怒无常的)头文件的奇怪问题，所以现在我避免使用它们。我不经常做一个完整的构建，通常把它留到一天结束的时候去散步一个小时(所以我只能猜测它需要大约半个小时)。所以我理解为什么这对于工作和测试是不可行的。

对于工作和测试，我为每个应用程序(或模块或库)都准备了另一组批处理文件，这些文件也具有所有的调试设置——但它们仍然调用相同的 make 文件。我可以时不时地关闭 DEBUG，也可以决定构建或制作，或者是否还要构建模块可能依赖的库，等等。

批处理文件还将完成的结果复制到(或多个)测试文件夹中。这取决于设置完成在几秒到一分钟(而不是说半个小时)。

我使用了不同的 IDE (Zeus) ，因为我喜欢控制。Rc 文件，并且实际上更喜欢从命令行编译，即使我使用的是 MS 编译器。

如果有人感兴趣，我很乐意发布这个批处理文件的示例。

Xoreax IB 的一个更便宜的替代方案是使用我所说的超级文件构建。基本上就是。的 cpp 文件

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

然后编译优步单元，而不是单独的模块。我们已经看到从10-15分钟到1-2分钟的编译时间。您可能需要试验每个优步文件包含多少个 # include 才有意义。那要看是什么项目了。等等。也许你包括10个文件，也许20个。

你要付出代价，所以要当心:

1. 您不能右键单击一个文件并说“编译...”，因为您必须从构建中排除单个 cpp 文件，并且只包含超级 cpp 文件
2. 您必须小心静态全局变量冲突。
3. 添加新模块时，必须更新优步文件

这是一种痛苦，但对于一个在新模块方面基本上是静态的项目来说，最初的痛苦可能是值得的。我见过这种方法在某些情况下击败 IB。

Chromium.org 团队列出了 加速建造的几个选项(在页面的中间位置) :

按加速的先后顺序排列:

• 安装 Microsoft 修复程序 935225。
• 安装 Microsoft 修复程序 947315。
• 使用真正的多核处理器(例如，英特尔酷睿双核2，而不是奔腾4 HT)。
• 使用3个并行构建。在 VisualStudio2005中，您将在 工具 > 选项... > 项目和解决方案 > 构建和运行 > 并行项目构建的最大数量中找到该选项。
• 禁用你的杀毒软件。同上。PDB.抄送。H 文件，只检查 修改上的病毒。禁用扫描源所在的目录。别做傻事。
• 在第二个硬盘上存储并构建 Chromium 代码。它不会真正加速构建，但至少在进行 gclient 同步或构建时，您的计算机将保持响应。
• 定期对硬盘进行碎片整理。
• 禁用虚拟内存。

你也许还想检查一下循环项目的参考资料，这曾经是我的一个问题。

那就是:

项目 A 参考项目 B

项目 B 参考项目 C

项目 C 引用项目 A

到目前为止有帮助的好的建议(不是说下面没有其他好的建议，如果你有问题，我建议你读一读，只是什么帮助了我们)

• 新的3GHz 笔记本电脑-当向管理层抱怨时，损失利用率的威力创造了奇迹
• 在编译期间禁用反病毒
• 在编译过程中“断开”与 VSS (实际上是网络)的连接——我可能会让我们完全移除 VS-VSS 集成，并坚持使用 VSS UI

仍然没有通过编译进行 Rip-snort，但是每一个位都有所帮助。

我们还在测试在新的解决方案中构建应用程序的新区域的实践，根据需要导入最新的 dls，当我们满意时，它们将它们集成到更大的解决方案中。

我们也可以通过创建临时解决方案来对现有代码进行同样的处理，这些临时解决方案只是封装了我们需要处理的区域，并在重新集成代码后将其丢弃。我们需要权衡重新集成这些代码所需要的时间和我们没有 Rip Van Winkle 那样在开发过程中快速重新编译的经验所获得的时间。

Orion 确实在评论中提到了仿制药也可能有用。从我的测试来看，性能确实受到了很小的影响，但是还没有高到可以确定的程度——由于磁盘活动，编译时间可能不一致。由于时间限制，我的测试没有包含在活动系统中出现的那么多泛型，或者那么多代码，因此可能会累积。我不会避免在应该使用泛型的地方使用泛型，只是为了编译时的性能

关闭杀毒软件，它会增加编译时间。

我们的主要解决方案中有80多个项目，根据开发人员所使用的机器类型，构建这些项目大约需要4到6分钟。我们认为这太长了: 对于每一个单独的测试，它真的会消耗你的 FTE。

那么如何更快地进行构建呢？正如您似乎已经知道的那样，真正影响构建时间的是项目的数量。当然，我们不想放弃所有的项目，只是简单地将所有源文件放在一个项目中。但是我们仍然可以组合一些项目: 由于解决方案中的每个“存储库项目”都有自己的单元测试项目，所以我们只是将所有单元测试项目组合成一个全局单元测试项目。这减少了大约12个项目的项目数量，并以某种方式节省了构建整个解决方案的40% 的时间。

不过，我们正在考虑另一种解决方案。

您是否也尝试过用一个新项目设置一个新的(第二个)解决方案？第二个解决方案应该简单地使用解决方案文件夹合并所有文件。因为您可能会惊讶地看到只有一个项目的新解决方案的构建时间。

然而，使用两种不同的解决方案需要仔细考虑。开发人员可能倾向于在第二个解决方案中实际工作，而完全忽视第一个。由于70 + 项目的第一个解决方案将是处理对象层次结构的解决方案，因此这应该是构建服务器应该运行所有单元测试的解决方案。因此，持续集成的服务器必须是第一个项目/解决方案。您必须维护您的对象层次结构，对吧。

只有一个项目的第二个解决方案(构建速度要快得多)将比由所有开发人员完成测试和调试的项目更好。但是你必须注意他们在构建服务器上的表现！如果有什么东西坏了，一定要修好。

确保您的引用是 Project 引用，而不是直接指向库输出目录中的 DLL。

另外，将这些设置为除非绝对必要(主 EXE 项目) ，否则不在本地进行复制。

禁用源目录上的文件系统索引(特别是 obj 目录，如果希望源目录可搜索的话)

我在一个有21个项目和50万 LOC 的解决方案上遇到过类似的问题。最大的区别是硬盘驱动器的速度更快。从性能监视器的‘ Avg。“磁盘队列”将在笔记本电脑上显著跳起，表明硬盘驱动器是瓶颈。

这里有一些重建总时间的数据..。

1)笔记本电脑，酷睿2双核2GHz，每分钟5400转(不确定是否缓存。是戴尔的标准灵感来源)。

重建时间 = 112秒。

2)台式机(标准配置) ，酷睿2 Duo 2.3 Ghz，单个7200RPM 硬盘8MB 缓存。

重建时间 = 72秒。

3)台式机酷睿2 Duo 3Ghz，单机10000 RPM WD Raptor

重建时间 = 39秒。

10,000转驱动器不能被低估。在构建过程中，使用文件浏览器显示文档等其他内容的速度明显更快。通过加速代码构建-运行周期，这是一个巨大的生产力提升。

考虑到公司在开发人员工资上的支出，他们可以浪费多少钱来购买与接待员使用的相同的个人电脑。

VS2008肯定有问题。因为我所做的唯一一件事就是安装 VS2008来升级我的项目，这个项目是用 VS2005创建的。 我的解决方案中只有两个项目，不是很大。 与 VS2005汇编: 30秒 用 VS2008编译: 5分钟

如果它是一个 C + + 项目，那么您应该使用预编译头文件。这对编译时间有很大的影响。不确定 cl.exe 实际上在做什么(没有使用预编译头) ，它似乎在所有错误的地方寻找 STL 头的 很多，然后最终到达正确的位置。这会增加每一秒的时间。正在编译的 cpp 文件。不确定这是 cl.exe 错误，还是 VS2008中的某种 STL 问题。

看看您正在构建的机器，它的配置是否最佳？

通过确保安装正确的 SATA 过滤器驱动程序，我们刚刚得到了我们最大的 C + + 企业级产品的构建时间，从 19个小时下降到 16分钟。

真狡猾。

我注意到这个问题已经有很长时间了，但是今天这个话题仍然很有趣。同样的问题最近也困扰着我，改善构建性能最多的两件事是: (1)使用专用(且快速)磁盘进行编译; (2)对所有项目使用相同的 outputfile，并在项目引用上将 CopyLocal 设置为 False。

一些额外资源:

• Https://stackoverflow.com/questions/8440/visual-studio-optimizations
• Http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• Http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• Http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

在 Visual Studio 2005中有一个未记录的/MP 开关，请参阅 http://lahsiv.net/blog/?p=40，它支持基于文件的并行编译，而不是基于项目的并行编译。这可能会加速最后一个项目的编译，或者，如果您编译了一个项目。

一些分析工具:

工具-> 选项-> VC + + 项目设置-> 构建时间 = 是 will tell you build time for every vcproj.

将 /Bt开关添加到编译器命令行，查看每个 CPP 文件占用了多少时间

使用 /showIncludes捕获嵌套包含(包含其他头文件的头文件) ，并查看哪些文件可以通过使用转发声明节省大量 IO。

这将帮助您通过消除依赖关系和性能占用来优化编译器性能。

在花钱投资更快的硬盘驱动器之前，尝试完全在 RAM 磁盘上构建项目(假设您有多余的 RAM)。您可以在网上找到各种免费的 RAM 磁盘驱动程序。您不会找到任何比 RAM 磁盘更快的物理驱动器，包括 SSD。

在我的案例中，一个项目花费5分钟构建在一个6核 i7的7200 RPM 的 SATA 驱动器上，使用一个 RAM 磁盘只减少了大约15秒。考虑到复制到永久存储的需要和丢失工作的可能性，15秒不足以激励使用 RAM 磁盘，可能也不足以激励花费几百美元在高转速或 SSD 驱动器上。

这个小小的改进可能表明构建是 CPU 绑定的，或者说 Windows 文件缓存相当有效，但是由于这两个测试都是在没有缓存文件的状态下进行的，所以我倾向于使用 CPU 绑定编译。

根据您正在编译的实际代码，您的收获可能会有所不同——所以不要犹豫进行测试。

当选择 CPU: L1缓存大小似乎对编译时间有很大的影响。此外，它通常是更好的有2个快的核心比4个慢的。Visual Studio 不能有效地使用额外的内核。(我是根据自己使用 C + + 编译器的经验得出这个结论的，但对于 C # 编译器来说，这可能也是正确的。)

我现在也确信 VS2008有问题。我正在运行它的双核心英特尔笔记本电脑与3G 内存，与反病毒关闭。编译这个解决方案通常是相当圆滑的，但是如果我一直在调试，随后的重新编译通常会慢得像爬行一样。从连续的主磁盘指示灯可以清楚地看出，存在磁盘 I/O 瓶颈(您也可以听到)。如果我取消构建并关闭 VS，磁盘活动将停止。重新启动 VS，重新加载解决方案，然后重新生成，这样会快得多。下次再见

我的想法是，这是一个内存分页问题-VS 只是运行的内存和 O/S 开始页面交换，试图腾出空间，但 VS 的要求超过页面交换可以提供，所以它放慢到一个爬行。我想不出别的解释了。

VS 绝对不是一个 RAD 工具，是吗？

在完成完整的构建之后，您的构建目录有多大？如果您坚持默认设置，那么您构建的每个程序集都会将其依赖项的所有 DLL 及其依赖项的依赖项等复制到其 bin 目录。在我之前的工作中，我的同事们在处理大约40个项目的解决方案时发现，到目前为止，构建过程中最昂贵的部分是一遍又一遍地复制这些程序集，而且一个构建可以一遍又一遍地生成相同 DLL 的千兆字节的副本。

下面是《 NDepend 》一书的作者帕特里克•斯马奇亚(Patrick Smacchia)提出的一些有用的建议，他认为什么应该和什么不应该是独立的程序集:

Http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

基本上有两种方法可以解决这个问题，但都有缺点。一个是减少装配的数量，这显然是一个很大的工作量。另一个方法是重构构建目录，以便合并所有 bin 文件夹，并且项目不复制它们的依赖项的 DLL ——它们不需要这样做，因为它们都已经在同一个目录中了。这大大减少了在构建过程中创建和复制的文件数量，但是设置起来可能很困难，并且可能使您很难只提取用于打包的特定可执行文件所需的 DLL。

我发现有一些东西对于加快构建 C #/. NET很有用:

• 将小项目合并为大项目，因为构建解决方案时每个项目的开销都很大。(如果需要控制跨层调用，可以使用 不一定)

• 将我们所有的项目构建到某个输出目录中，然后在所有的项目引用上将“ copy local”设置为 false ——由于 IO 减少，这可能导致大幅度的加速。

• 转动你的病毒检查器，看看它是否有很大的不同; 如果是这样，找到一个 更快的病毒检测器，或从病毒检查器扫描排除“热”文件夹

• 使用 perforce 监视器和 sys 内部工具查看编译花费的时间。

• 考虑将输出目录放在内存磁盘上。

• 考虑使用「额外印花税」

• 更多的内存有时会产生很大的影响-(如果删除一个小内存会大大降低机器的速度，那么增加更多内存可能会大大提高机器的速度) 删除不需要的项目引用(您可能必须首先删除不需要的“使用”)

• 考虑在最底层使用依赖注入框架和接口，所以只有当接口发生变化时才需要重新编译所有内容——这可能不会取决于接口发生变化的频率。

有关将 VisualStudio 编译时间减少到几秒钟的说明

遗憾的是，VisualStudio 不够聪明，无法区分程序集的接口更改和无关紧要的代码体更改。这个事实，当与一个大型的相互交织的解决方案结合在一起时，有时几乎每当您更改一行代码时，都会产生一场不必要的“完整构建”的完美风暴。

克服这一点的一个策略是禁用自动引用树生成。要做到这一点，使用“配置管理器”(构建/配置管理器... 然后在活动解决方案配置下拉菜单中，选择“新建”)来创建一个名为“ ManualCompile”的新构建配置，该配置复制调试配置，但不要选中“创建新项目配置”复选框。在这个新的生成配置中，取消选中每个项目，这样它们都不会自动生成。通过点击“关闭”来保存这个配置。此新生成配置将添加到解决方案文件中。

您可以通过 IDE 屏幕顶部的构建配置下拉菜单(通常显示“ Debug”或“ Release”)从一个构建配置切换到另一个构建配置。有效地，这个新的 ManualCompile 构建配置将使“构建解决方案”或“重新构建解决方案”的“构建”菜单选项失效。因此，当您处于 ManualCompile 模式时，您必须手动构建您正在修改的每个项目，这可以通过在解决方案资源管理器中右键单击每个受影响的项目，然后选择“ Build”或“ Rebuild”来完成。您应该看到，现在整个编译时间将只有几秒钟。

为了使这个策略有效，AssemblyInfo 和 GlobalAssemblyInfo 文件中的 VersionNumber 必须在开发人员的机器上保持静态(当然不是在发布版本构建期间) ，并且不要签署 DLL。

使用这种 ManualCompile 策略的一个潜在风险是，开发人员可能会忘记编译所需的项目，并且当他们启动调试器时，会得到意外的结果(无法附加调试器、找不到文件等)。为了避免这种情况，最好使用“ Debug”构建配置来编译更大的编码工作，并且只在单元测试期间使用 ManualCompile 构建配置，或者在有限的范围内进行快速更改。

我们在一个解决方案中有近100个项目，而开发人员的构建时间只有几秒钟:)

对于本地开发构建，我们创建了一个 Visual Studio Addin，它将 Project references更改为 DLL references并卸载不需要的项目(当然还有一个将它们切换回来的选项)。

• 构建我们的整个解决方案 一次
• 卸载当前不正在处理的项目，并将所有项目引用更改为 DLL 引用。
• 在签入之前，将所有引用从 DLL 更改回项目引用。

现在，当我们一次只处理几个项目时，我们的构建只需要几秒钟。我们还可以在附加项目链接到调试 DLL 时调试它。该工具通常需要10-30秒才能进行大量更改，但是您不必经常这样做。

2015年5月最新情况

我所做的交易(在下面的评论中)是，我将把这个插件发布到 Open Source 如果上，它会引起足够的兴趣。4年后，它只有44票(Visual Studio 现在有两个后续版本) ，所以它目前是一个低优先级的项目。

我发现以下方法有助于提高编译速度: 在重复编译(内存中的迭代开发)之后，我将退出 VS2008。然后进入项目目录，删除所有的 obj和 bin文件夹，重新启动项目，我的编译时间就下降了。这类似于 VS2008中的 Clean solution动作。

只是想确认一下这个对外面的人有没有用。

我在这里找到了解决办法: http://blogs.msdn.com/b/vsdteam/archive/2006/09/15/756400.aspx

为了 C # 。NET 生成时，可以使用 .NET 恶魔。它是一个接管 VisualStudio 构建过程的产品，以使其更快。

它通过分析您所做的更改来实现这一点，并且只构建您实际更改的项目，以及实际依赖于您所做的更改的其他项目。这意味着如果只更改内部代码，则只需生成一个项目。

贵公司是否碰巧使用委托来提供 PKI/加密解决方案？事实证明，对于一个用 C # 构建的相当大的网站，我们的构建性能非常糟糕，在 Rebuild-All 上花了7分多钟。

我的机器是 i7-3770，内存为16GB，固态硬盘为512GB，所以性能应该没有那么差。我注意到，在构建相同代码库的旧的辅助计算机上，我的构建时间快得惊人。所以我在两台机器上都启动了 ProcMon，对构建进行了分析，并比较了结果。

看吧，性能较慢的机器有一个不同之处——在堆栈跟踪中引用了 Entrust. dll。使用这个新获得的信息，我继续搜索 StackOverflow 并找到了这个: MSBUILD (VS2010)在某些机器上非常慢。根据接受的答案，问题在于 Entrust 处理程序正在处理。NET 证书检查而不是本机 Microsoft 处理程序。还建议 Entrust v10解决 Entrust 9中普遍存在的这个问题。

我目前有它卸载和我的构建时间直线下降到 24秒。YYMV 包含您当前正在构建的项目数量，可能无法直接解决您所询问的伸缩性问题。如果我可以提供一个修复 没有诉诸于卸载软件，我将发布一个编辑到这个响应。

慢视觉工作室性能... 解决！ 2014年9月24日乌兹玛 · 阿比迪

我今天的表现有点问题。我的 MicrosoftVisualStudio 似乎花费了太长的时间来执行即使是最简单的操作。我四处搜索，尝试了一些人们的想法，比如禁用外接程序或清除 Visual Studio 最近的项目列表，但这些建议似乎并没有解决问题。我记得 Windows SysInternals 网站上有一个名为 Process Monitor 的工具，可以嗅探任何正在运行的程序对注册表和文件的访问。在我看来，Visual Studio 似乎正在忙于某些事情，流程监视器应该帮助我弄清楚它是什么。我下载了最新的版本，在对它的显示过滤器做了一些调整之后，运行了它，令我惊恐的是，我发现 Visual Studio 的速度如此之慢，因为它在大多数 IDE 操作中访问了 C: Users krintoul AppData Local Microsoft WebSiteCache 中的10,000多个文件夹。我不知道为什么会有这么多文件夹，而且，我也不知道 Visual Studio 是怎么处理这些文件夹的，但是当我把这些文件夹拉上拉链，移到其他地方后，Visual Studio 的性能得到了极大的改善。

WindowsSysInternals 网站还有许多其他有用的实用工具，用于网络管理、安全、系统信息等。看看这个。我相信你会找到有价值的东西。