我们的编译时间很慢，在双核2GHz，2G Ram机器上可能要花费20多分钟的时间。

这主要归因于我们的解决方案的规模（已发展到70多个项目），以及VSS（当您拥有大量文件时，它本身就是瓶颈）。（不幸的是，换掉VSS并不是一个选择，所以我不希望它沦落为VSS的狂欢）

我们正在考虑合并项目。我们还在寻找具有多种解决方案的解决方案，以实现问题的更大分离，并为应用程序的每个元素缩短编译时间。当我们尝试保持同步时，我可以看到这将变成DLL地狱。

我很想知道其他团队是如何处理此扩展问题的，当您的代码库达到临界值时，您会怎么做？您浪费了半天时间在状态栏上查看编译消息。

UPDATE 我忽略了提及这是一个C＃解决方案。感谢所有C ++的建议，但是距离我不得不担心头文件已经过去了几年了。

编辑：

到目前为止已经有用的好建议（不是说下面没有其他好建议了，只是有什么帮助了）

• 新型3GHz笔记本电脑-失去管理的能力使管理时产生奇迹
• 在编译过程中禁用反病毒
• 编译期间与VSS（实际上是网络）的“断开连接”-我可能会让我们完全删除VS-VSS集成，并坚持使用VSS UI

仍然不能通过编译进行反复操作，但是一点点都可以。

Orion在评论中确实提到了仿制药也可能发挥作用。从我的测试来看，确实确实对性能的影响最小，但是不足以确保-由于光盘活动，编译时间可能不一致。由于时间限制，我的测试未包含实时系统中出现的那么多泛型或代码，因此可能会累积。我不会避免在应该使用泛型的地方使用它们，只是为了提高编译时的性能。

解决方法

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

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

Chromium.org团队列出了一些加快构建的选项（此时大约在页面的一半）：

按降速顺序：

• 安装Microsoft修补程序935225。
• 安装Microsoft修补程序947315。
• 使用真正的多核处理器（即Intel Core Duo 2；而不是Pentium 4 HT）。
• 使用3个并行构建。在Visual Studio 2005中，您可以在“ 工具”>“选项...”>“项目和解决方案”>“构建和运行”>“最大并行项目构建数”中找到该选项。
• 禁用防病毒软件.ilk，.PDB和.cc，.h文件，只检查对病毒修改。禁用扫描源所在目录。不要做任何愚蠢的事情。
• 在另一个硬盘驱动器上存储并构建Chromium代码。它并不能真正加快构建速度，但是当您执行gclient同步或构建时，至少您的计算机将保持响应。
• 定期对硬盘驱动器进行碎片整理。
• 禁用虚拟内存。

一个解决方案中有近100个项目，而开发构建时间只有几秒钟：)

对于本地开发版本，我们创建了一个Visual Studio加载项的更改Project references，以DLL references和卸载不需要的项目（和选项，可以将切换回当然）。

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

现在，当我们一次仅处理几个项目时，构建只需几秒钟。当我们链接到调试DLL时，我们仍然可以调试其他项目。该工具通常需要10到30秒钟来进行大量更改，但是您不必经常这样做。

2015年5月更新

我做了（在下面的评论）的交易，是我将释放插件开源，如果它得到足够的兴趣。4年后，它只有44票（而Visual Studio现在有两个后续版本），因此它目前是一个低优先级的项目。

对于21个项目和1/2百万LOC的解决方案，我也遇到了类似的问题。最大的不同是获得更快的硬盘驱动器。在效果监视器中，“平均 “磁盘队列”将在笔记本电脑上大幅跳升，表明硬盘驱动器是瓶颈。

以下是重建总时间的一些数据...

1）笔记本电脑，Core 2 Duo 2GHz，5400 RPM驱动器（不确定缓存。是标准的Dell inspiron）。

重建时间= 112秒。

2）台式机（标准版），Core 2 Duo 2.3Ghz，单个7200RPM驱动器8MB缓存。

重建时间= 72秒。

3）Desktop Core 2 Duo 3Ghz，单个10000 RPM WD Raptor

重建时间= 39秒。

10,000 RPM驱动器不可低估。使用File Explorer可以显着加快构建速度，以及显示文档等其他所有内容的速度更快。通过加快代码构建-运行周期，这极大地提高了生产率。

鉴于公司花在开发人员薪水上的钱真是太疯狂了，他们浪费多少钱购买与接待员使用的PC相同的PC。

对于C＃.NET构建，可以使用.NET Demon。它是一个产品，它接管了Visual Studio的构建过程以使其更快。

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

关闭您的防病毒软件。它增加了编译时间。

使用分布式编译。Xoreax IncrediBuild可以将编译时间减少到几分钟。

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

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

不幸的是，Visual Studio不够聪明，无法区分程序集的界面更改和无关紧要的代码主体更改。这个事实与大量相互关联的解决方案结合在一起时，几乎每次您更改一行代码时，有时都可能会引起不想要的“完整版本”的风暴。

解决此问题的策略是禁用自动参考树构建。为此，请使用“配置管理器”（“构建/配置管理器...”，然后在“活动解决方案”配置下拉列表中，选择“新建”）创建一个名为“ ManualCompile”的新构建配置，该配置将从Debug配置复制，但是不要选中“创建新项目配置”复选框。在这个新的构建配置中，取消选中每个项目，以便它们都不会自动构建。点击“关闭”以保存此配置。此新的构建配置已添加到您的解决方案文件中。

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

为了使此策略起作用，必须在AssemblyInfo和GlobalAssemblyInfo文件中找到的VersionNumber在开发人员的计算机上保持静态（当然，在发行版本期间不这样），并且您不对DLL进行签名。

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

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

我们的主要解决方案中有80多个项目，构建时间大约需要4至6分钟，具体取决于开发人员使用的是哪种机器。我们认为这太长了：对于每一项测试，它确实会吞噬您的FTE。

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

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

您是否还尝试过为新项目设置新的（第二个）解决方案？第二种解决方案应仅使用解决方案文件夹合并所有文件。因为您可能会惊讶地看到这个只有一个项目的新解决方案的构建时间。

但是，使用两种不同的解决方案将需要谨慎考虑。开发人员可能倾向于实际使用第二个解决方案，而完全忽略第一个解决方案。由于涉及70多个项目的第一个解决方案将是解决对象层次结构的解决方案，因此这应该是构建服务器应运行所有单元测试的解决方案。因此，用于持续集成的服务器必须是第一个项目/解决方案。您必须维护对象层次结构。

第二个解决方案只有一个项目（构建速度会更快），而不是所有开发人员都将进行测试和调试的项目。不过，您必须照顾他们，看看buildserver！如果有任何问题，必须修复。

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

另外，将它们设置为除非绝对必要（主EXE项目），否则不要在本地复制。

我最初将此响应发布在此处：https : //stackoverflow.com/questions/8440/visual-studio-optimizations#8473 您可以在该页面上找到许多其他有用的提示。

如果使用的是Visual Studio 2008，则可以使用/ MP标志进行编译以并行构建单个项目。我读过，这也是Visual Studio 2005中未记录的功能，但从未尝试过。

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

我注意到这个问题已有很长的历史了，但是今天这个话题仍然很有趣。最近，同样的问题困扰着我，并且最大程度提高了构建性能的两件事是：（1）使用专用（且快速）的磁盘进行编译；（2）对所有项目使用相同的输出文件夹，然后在项目上将CopyLocal设置为False参考。

一些其他资源：

• /programming/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/

一些分析工具：

工具->选项-> VC ++项目设置->构建时间=是将告诉您每个vcproj的构建时间。

将/Bt开关添加到编译器命令行以查看每个CPP文件花费了多少

使用/showIncludes渔获嵌套包含（头文件包含其他头文件），并查看哪些文件可以通过使用前置声明节省了大量的IO。

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

在花钱购买更快的硬盘驱动器之前，请尝试完全在RAM磁盘上构建项目（假设您有剩余的RAM）。您可以在网上找到各种可用的RAM磁盘驱动器。您找不到比RAM磁盘快的任何物理驱动器，包括SSD。

以我为例，一个使用Incredibuild在7200 RPM SATA驱动器上的6核i7上构建耗时5分钟的项目通过使用RAM磁盘仅减少了约15秒。考虑到需要重新复制到永久存储以及可能丢失工作的可能，因此15秒不足以激励用户使用RAM磁盘，而对花费数百美元购买高RPM或SSD驱动器的激励可能也不足。

收益不大可能表明该版本受CPU约束或Windows文件缓存相当有效，但是由于这两个测试都是在未缓存文件的状态下进行的，因此我倾向于使用CPU约束的编译。

根据您所编写的实际代码，里程可能会有所不同-因此请不要犹豫进行测试。

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

这是NDepend的作者Patrick Smacchia提出的一些有用的建议，关于他认为应该和不应该将其作为单独的程序集的建议：

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

解决此问题的方法基本上有两种，但都有缺点。一种是减少装配的数量，这显然是很多工作。另一个方法是重组构建目录，以便合并所有bin文件夹，并且项目不会复制其依赖项的DLL-不需要，因为它们已经位于同一目录中。这极大地减少了在构建过程中创建和复制的文件数量，但是可能很难设置，并且使您仅抽出特定可执行文件打包所需的DLL时遇到一些困难。

也许采用一些通用功能并创建一些库，这样就不会为多个项目一遍又一遍地编译相同的源代码。

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

关闭VSS集成。您可能无法选择使用它，但是DLL总是被“偶然地”重命名...

并绝对检查您的预编译头设置。布鲁斯·道森（Bruce Dawson）的指南有些陈旧，但仍然非常出色-请查看：http : //www.cygnus-software.com/papers/precompiledheaders.html

我有一个包含120个或更多exe，lib和dll的项目，并且花费大量时间来构建。我使用一棵批处理文件树，它们从一个主批处理文件中调用make文件。过去，我遇到过来自增量（或气质）标题中奇怪内容的问题，因此现在就避免使用它们。我很少进行完整的构建，通常在一天散步一个小时后才放到一天结束时（所以我只能猜测大约需要半个小时）。因此，我了解为什么这对于工作和测试不可行。

对于工作和测试，我为每个应用程序（或模块或库）提供了另一组批处理文件，这些批处理文件还具有所有调试设置-但它们仍调用相同的make文件。我可能会不时关闭DEBUG的开关，并决定是在构建还是进行构建，或者是否还要构建模块可能依赖的库，依此类推。

批处理文件还将完成的结果复制到（或几个）测试文件夹中。根据设置，此过程将在几秒钟到一分钟（而不是半个小时）内完成。

我喜欢使用其他IDE（Zeus），因为我喜欢控制.rc文件之类的东西，并且即使在使用MS编译器的情况下，我实际上更喜欢从命令行进行编译。

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

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

如果这是一个Web应用程序，则根据情况将批处理构建设置为true可能会有所帮助。

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

您可以在此处找到概述：http : //weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

您可能还需要检查循环项目参考。这对我来说曾经是一个问题。

那是：

项目A参考项目B

项目B参考项目C

项目C参考项目A

Xoreax IB的一种更便宜的替代方法是使用我所谓的uber文件构建。它基本上是一个.cpp文件，具有

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

然后，编译超级单元，而不是各个模块。我们已经看到编译时间从10-15分钟减少到1-2分钟。您可能需要估算每个uber文件中多少个#include才有意义。取决于项目。等等。也许您包括10个文件，也许是20个。

您要付费，所以请注意：

1. 您不能右键单击文件并说“ compile ...”，因为您必须从构建中排除单个cpp文件，而仅包括uber cpp文件
2. 您必须小心静态全局变量冲突。
3. 添加新模块时，必须使uber文件保持最新状态

这有点痛苦，但是对于一个在新模块方面基本上是静态的项目，初期的痛苦可能是值得的。我已经看到这种方法在某些情况下优于IB。

如果是C ++项目，则应该使用预编译的头文件。这在编译时间上有很大的不同。不知道cl.exe到底在做什么（不使用预编译的头文件），似乎在所有错误的地方都找到了许多 STL头文件，然后才最终找到正确的位置。这将整个秒数添加到正在编译的每个.cpp文件中。不知道这是cl.exe错误，还是VS2008中存在某种STL问题。

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

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

微妙。

Visual Studio 2005中有未记录的/ MP开关，请参阅http://lahsiv.net/blog/?p=40，该开关将允许基于文件而不是基于项目的并行编译。这可以加快最后一个项目的编译速度，或者如果您编译一个项目，则可以加快编译速度。

选择CPU时：L1高速缓存大小似乎对编译时间有很大影响。同样，通常有2个快速内核比4个慢速内核更好。Visual Studio不能非常有效地使用额外的内核。（这是基于我在C ++编译器上的经验，但是对于C＃来说也可能是正确的。）

我现在也确信VS2008存在问题。我正在具有3G Ram的双核Intel笔记本电脑上运行它，并且已关闭了防病毒功能。编译解决方案通常很麻烦，但是如果我一直在调试，那么随后的重新编译通常会减慢爬网速度。从持续的主磁盘指示灯可以清楚地看到磁盘I / O瓶颈（您也可以听到）。如果取消构建和关闭VS，磁盘活动将停止。重新启动VS，重新加载解决方案，然后重新构建，它的速度要快得多。下次统一

我的想法是这是一个内存分页问题-VS刚用完内存，O / S开始页面交换以尝试腾出空间，但是VS要求的内容超出了页面交换可以提供的范围，因此它减慢了爬网的速度。我想不出任何其他解释。

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

贵公司是否偶然将Entrust用于其PKI /加密解决方案？事实证明，对于使用C＃构建的相当大的网站，我们的构建性能令人震惊，整个Rebuild-All花费了7分钟以上的时间。

我的机器是配备16GB内存和512GB SSD的i7-3770，因此性能应该不会那么差。我注意到在构建相同代码库的旧式辅助计算机上，我的构建时间快得惊人。因此，我在两台计算机上启动了ProcMon，分析了构建并比较了结果。

瞧，运行缓慢的计算机有一个区别-在stacktrace中对Entrust.dll的引用。使用此新获取的信息，我继续搜索StackOverflow并发现：MSBUILD（VS2010）在某些计算机上非常慢。根据公认的答案，问题在于，Entrust处理程序正在处理.NET证书检查，而不是本机Microsoft处理程序。还建议Tt Entrust v10解决此问题，此问题在Entrust 9中很普遍。

我目前已将其卸载，构建时间骤降至24秒。包含您当前正在构建的项目数的YYMV，可能无法直接解决您正在询问的扩展问题。如果我可以不通过卸载软件来提供修复程序，则将对此响应发布编辑。

可以确定VS2008存在问题。因为我唯一要做的就是安装VS2008，以升级由VS2005创建的项目。我的解决方案中只有2个项目。不大 VS2005编译：30秒VS2008编译：5分钟

到目前为止已经有用的不错的建议（不要说下面没有其他不错的建议，如果您遇到问题，我建议您先阅读一下，看看对我们有什么帮助）

• 新型3GHz笔记本电脑-失去管理的能力使管理时产生奇迹
• 在编译过程中禁用反病毒
• 编译期间与VSS（实际上是网络）的“断开连接”-我可能会让我们完全删除VS-VSS集成，并坚持使用VSS UI

仍然不能通过编译进行反复操作，但是一点点都可以。

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

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

Orion在评论中确实提到了仿制药也可能发挥作用。从我的测试来看，确实确实对性能的影响最小，但是不足以确保-由于光盘活动，编译时间可能不一致。由于时间限制，我的测试未包含实时系统中出现的那么多泛型或代码，因此可能会累积。我不会避免在应该使用泛型的地方使用它们，只是为了提高编译时的性能。