我们的编译时间非常慢，在双核2GHz，2G Ram机器上可能需要20多分钟。
这很大程度上是由于我们的解决方案已经发展到70多个项目，以及VSS，当你拥有大量文件时，它本身就是瓶颈。 （不幸的是，交换VSS不是一个选项，所以我不希望这种情况下降到VSS bash中）
我们正在考虑合并项目。我们还在寻找多种解决方案，以便为应用程序的每个元素实现更大的关注点分离和更快的编译时间。我可以看到这将成为一个DLL地狱，因为我们试图保持同步。
我很想知道其他团队是如何处理这个扩展问题的，当你的代码库达到一个临界质量时你会怎么做，你正在看着状态栏传递编译消息的一半时间。
更新 我忽略了这是一个C＃解决方案。感谢所有的C ++建议，但是我已经有几年了，因为我不得不担心标题。
修改
到目前为止已经提供了很好的建议（不是说下面没有其他好的建议，只是有所帮助）
仍然没有通过编译窃听，但每一点都有帮助。
Orion确实在评论中提到仿制药也可能有戏剧性。从我的测试来看，似乎确实有最小的性能损失，但不足以确定 - 由于光盘活动，编译时间可能不一致。由于时间限制，我的测试没有包含与实时系统中出现的一样多的泛型或代码，因此可能会累积。我不会避免在它们应该被使用的地方使用泛型，只是为了编译时间性能解决方法
我们正在测试在新解决方案中构建应用程序新领域的实践，根据需要导入最新的dll，当我们对它们满意时，将它们集成到更大的解决方案中。
我们也可以通过创建临时解决方案来对现有代码执行相同的操作，这些解决方案仅封装我们需要处理的区域，并在重新集成代码后将它们丢弃。我们需要权衡重新整合这些代码所需的时间，而不是让Rip Van Winkle在开发过程中快速重新编译时获得经验。
答案 0 :(得分：74)
Chromium.org团队为accelerating the build列出了几个选项（目前大约在页面的一半）：
按加速顺序递减：
- 安装Microsoft修补程序935225。
- 安装Microsoft修补程序947315。
- 使用真正的多核处理器（即Intel Core Duo 2;而不是Pentium 4 HT）。
- 使用3个并行版本。在Visual Studio 2005中，您将在工具＆gt;中找到该选项。选项......＆gt;项目和解决方案＆gt;构建并运行＆gt;最大并行项目构建数。
- 禁用.ilk，.pdb，.cc，.h文件的防病毒软件，仅检查修改上的病毒。禁用扫描源所在的目录。不要做任何愚蠢的事。
- 在第二个硬盘驱动器上存储并构建Chromium代码。它不会真正加速构建，但至少当你进行gclient同步或构建时，你的计算机将保持响应。
- 定期对硬盘进行碎片整理。
- 禁用虚拟内存。
答案 1 :(得分：58)
对于本地开发版本，我们创建了一个Visual Studio Addin，它将Project references更改为DLL references并卸载不需要的项目（当然还有一个选项可以将它们切换回来）。
我们的构建现在只需几秒钟，我们一次只处理几个项目。我们还可以在链接到调试DLL时调试其他项目。该工具通常需要10-30秒才能进行大量更改，但您不必经常这样做。
我做的交易（在下面的评论中）是，如果获得足够的兴趣，我会将该插件发布到开源。 4年后它只有44票（而Visual Studio现在有两个后续版本），所以它目前是一个低优先级的项目。
答案 2 :(得分：24)
我在21个项目和250万个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驱动器不容低估。构建显着更快，加上其他所有内容，如显示文档，使用文件浏览器显然更快。通过加快代码构建运行周期，可以大大提高生产力。
考虑到公司花在开发人员工资上的费用，疯狂他们可以浪费多少钱购买他们使用与接待员使用相同的PC。 的
答案 3 :(得分：16)
对于C＃.NET版本，您可以使用.NET Demon。它是一个接管Visual Studio构建过程以使其更快的产品。
它通过分析您所做的更改来完成此操作，并仅构建您实际更改的项目，以及实际依赖您所做更改的其他项目。这意味着如果您只更改内部代码，则只需要构建一个项目。
答案 4 :(得分：14)
关闭防病毒软件。它增加了编译时间。
答案 5 :(得分：12)
使用分布式编译。 Xoreax IncrediBuild可以将编译时间缩短到几分钟。
我在一个庞大的C \ C ++解决方案中使用它，通常需要5-6个小时来编译。 IncrediBuild帮助将这个时间减少到15分钟。
答案 6 :(得分：11)
将Visual Studio编译时间缩短到几秒的说明
遗憾的是，Visual Studio不够聪明，无法将程序集的界面更改与无关紧要的代码体更改区分开来。这一事实与大型交织解决方案相结合，有时可以在每次更改单行代码时创建一个完美的不必要的“完整构建”风暴。
要克服此问题的策略是禁用自动引用树构建。要执行此操作，请使用“Configuration Manager”（构建/配置管理器...然后在“活动解决方案配置”下拉列表中选择“新建”）以创建一个名为“ManualCompile”的新构建配置，该配置从Debug配置进行复制，但是不选中“创建新项目配置”复选框。在这个新的构建配置中，取消选中每个项目，以便它们不会自动构建。点击“关闭”保存此配置。此新构建配置将添加到您的解决方案文件中。
您可以通过IDE屏幕顶部的构建配置下拉列表（通常显示'Debug'或'Release'）从一个构建配置切换到另一个构建配置。实际上，这个新的ManualCompile构建配置将使“构建解决方案”或“重建解决方案”的构建菜单选项无效。因此，当您处于ManualCompile模式时，必须手动构建要修改的每个项目，这可以通过在解决方案资源管理器中右键单击每个受影响的项目，然后选择“构建”或“重建”来完成。您应该看到整个编译时间现在只需几秒钟。
要使此策略起作用，必须使AssemblyInfo和GlobalAssemblyInfo文件中的VersionNumber在开发人员的计算机上保持静态（当然不是在发布版本期间），并且不要对DLL进行签名。
使用此ManualCompile策略的潜在风险是开发人员可能忘记编译所需的项目，并且当他们启动调试器时，他们会得到意外的结果（无法附加调试器，找不到文件等）。为避免这种情况，最好使用“Debug”构建配置来编译更大的编码工作，并且仅在单元测试期间使用ManualCompile构建配置或进行范围有限的快速更改。
答案 7 :(得分：8)
如果这是C或C ++，并且您没有使用预编译的标题，那么您应该是。
答案 8 :(得分：7)
确保您的引用是Project引用，而不是直接指向库输出目录中的DLL。
此外，将这些设置为不在本地复制，除非绝对必要（主EXE项目）。
答案 9 :(得分：7)
我们的主要解决方案中有80多个项目，需要大约4到6分钟才能构建，具体取决于开发人员正在使用哪种机器。我们认为这太长了：每次测试都会让你的FTE真的吃掉。
那么如何加快构建时间？正如您似乎已经知道的那样，真正损害构建时间的项目数量。当然，我们不想摆脱所有项目，只需将所有源文件合并为一个。但是我们有一些项目可以合并：由于解决方案中的每个“知识库项目”都有自己的单元测试项目，我们只需将所有单元测试项目合并为一个全局单元测试项目。这减少了大约12个项目的项目数量，并以某种方式节省了40％的时间来构建整个解决方案。
我们正考虑另一种解决方案。
您是否也尝试使用新项目设置新的（第二个）解决方案？第二个解决方案应该只使用解决方案文件夹合并所有文因为您可能会惊讶地看到新解决方案的构建时间 - 只需一个项目。
然而，使用两种不同的解决方案需要仔细考虑。开发人员可能倾向于在第二个解决方案中实际工作，而完全忽略第一个解决方案。由于70多个项目的第一个解决方案将是处理对象层次结构的解决方案，因此这应该是构建服务器应运行所有单元测试的解决方案。因此，Continous Integration的服务器必须是第一个项目/解决方案。你必须维护你的对象层次结构。
只有一个项目（构建速度更快）的第二个解决方案将是所有开发人员完成测试和调试的项目。你必须照顾他们看看构建服务器！如果有什么破坏必须修复。
答案 10 :(得分：6)
我原来在这里发布了这个回复： https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 您可以在该页面上找到许多其他有用的提示。
如果您使用的是Visual Studio 2008，则可以使用/ MP标志进行编译，以并行构建单个项目。我已经读过，这也是Visual Studio 2005中的一个未记录的功能，但从未尝试过。
您可以使用/ M标志并行构建多个项目，但这通常已设置为计算机上的可用核心数，但这仅适用于我认为的VC ++。
答案 11 :(得分：6)
我注意到这个问题已经很久了，但今天这个话题仍然很有意思。同样的问题最近让我感到困惑，最能提高构建性能的两件事是：（1）使用专用（和快速）磁盘进行编译;（2）对所有项目使用相同的输出文件夹，并在项目中将CopyLocal设置为False引用。
一些额外的资源：
答案 12 :(得分：5)
一些分析工具：
tools-＆gt; options-＆gt; VC ++项目设置 - ＆gt;构建时间=是 会告诉你每个vcproj的构建时间。
将/Bt开关添加到编译器命令行以查看每个CPP文件花了多少
使用/showIncludes来捕获嵌套的包含（包含其他头文件的头文件），并查看哪些文件可以通过使用前向声明来节省大量IO。
这将通过消除依赖性和性能损失来帮助您优化编译器性能。
答案 13 :(得分：5)
在花钱购买更快的硬盘之前，请尝试完全在RAM磁盘上构建您的项目（假设您有可用的RAM）。您可以在网上找到各种免费的RAM磁盘驱动程序。您将找不到比RAM磁盘更快的任何物理驱动器，包括SSD。
在我的情况下，使用RAM磁盘，在带有Incredibuild的7200 RPM SATA驱动器上花费5分钟构建6核i7的项目仅减少了大约15秒。考虑到需要重新复制到永久存储和丢失工作的可能性，15秒不足以激励使用RAM磁盘，并且可能没有太多动力在高RPM或SSD驱动器上花费数百美元。
小增益可能表明构建受CPU限制或Windows文件缓存相当有效，但由于两个测试都是在未缓存文件的状态下完成的，因此我严重依赖于CPU绑定编译。
根据您编制的实际代码，您的里程可能会有所不同 - 所以请不要犹豫。
答案 14 :(得分：3)
完成构建后，构建目录有多大？如果您坚持使用默认设置，那么您构建的每个程序集都会将其依赖项的所有DLL及其依赖项的依赖项等复制到其bin目录中。在我以前的工作中使用~40个项目的解决方案时，我的同事发现，到目前为止，构建过程中最昂贵的部分是反复复制这些程序集，并且一个构建可以生成相同DLL的千兆字节副本。再一次。
以下是NDepend的作者Patrick Smacchia的一些有用的建议，他认为应该和不应该是单独的集会：
基本上有两种方法可以解决这个问题，两者都有缺点。一个是减少组件数量，这显然是很多工作。另一个是重构您的构建目录，以便合并所有bin文件夹，并且项目不会复制其依赖项的DLL - 它们不需要，因为它们都已在同一目录中。这大大减少了在构建期间创建和复制的文件数量，但是设置起来可能很困难，并且可能会使您难以仅删除特定可执行文件所需的DLL以进行打包。
答案 15 :(得分：2)
我有一个项目有120个或更多的exes，libs和dll，需要相当长的时间来构建。我使用一个批处理文件树，从一个主批处理文件调用make文件。我在过去使用增量（或者是气质）标题时遇到了奇怪的问题，所以我现在就避开它们。我不经常做一个完整的构建，并且通常在我散步一小时的时候离开它（所以我只能猜测它需要大约半小时）。所以我理解为什么这对于工作和测试来说是行不通的。
对于工作和测试，我为每个应用程序（或模块或库）提供了另一组批处理文件，这些文件也具有所有调试设置 - 但这些仍然调用相同的make文件。我可能会不时地关闭DEBUG并决定构建或制作或者我是否还要构建模块可能依赖的库等等。
批处理文件还将完成的结果复制到（或多个）测试文件夹中。根据设置，这在几秒到一分钟内完成（而不是半小时）。
我使用了不同的IDE（Zeus），因为我喜欢控制像.rc文件这样的东西，实际上更喜欢从命令行编译，即使我使用的是MS编译器。
如果有兴趣的话，很高兴发布这个批处理文件的示例。
答案 16 :(得分：2)
关闭VSS集成。您可能没有选择使用它，但DLL会被“意外”重命名......
绝对检查您的预编译标头设置。布鲁斯道森的指南有点旧，但仍然非常好 - 检查一下：http://www.cygnus-software.com/papers/precompiledheaders.html
答案 17 :(得分：2)
禁用源目录上的文件系统索引（特别是obj目录，如果您希望源代码可搜索）
答案 18 :(得分：2)
也许需要一些常用函数并创建一些库，这样就不会为多个项目反复编译相同的源代码。
如果您担心混合的不同版本的DLL，请使用静态库。
答案 19 :(得分：1)
您的公司是否碰巧使用Entrust的PKI /加密解决方案？事实证明，我们在一个用C＃构建的相当大的网站上拥有糟糕的构建性能，在Rebuild-All上花了7分多钟。
我的机器是配备16GB RAM和512GB SSD的i7-3770，所以性能不应该那么差。我注意到在构建相同代码库的旧辅助计算机上，我的构建时间非常快。所以我在两台机器上启动了ProcMon，分析了构建，并对结果进行了比较。
瞧，这台性能缓慢的机器有一个区别 - 在堆栈跟踪中引用了Entrust.dll。使用这个新获得的信息，我继续搜索StackOverflow并发现：MSBUILD (VS2010) very slow on some machines。根据公认的答案，问题在于Entrust处理程序正在处理.NET证书检查而不是本机Microsoft处理程序。还建议Entrust v10解决Entrust 9中普遍存在的这个问题。
我目前已将其卸载，我的构建时间暴跌至 24秒。 YYMV包含您当前正在构建的项目数量，可能无法直接解决您要查询的扩展问题。如果我可以提供修复而无需卸载该软件，我将对此响应发布一个编辑。
答案 20 :(得分：1)
我现在也确信VS2008存在问题。我在带有3G Ram的双核英特尔笔记本电脑上运行它，关闭了防病毒软件。编译解决方案通常非常灵活，但如果我一直在调试，后续重新编译通常会慢下来爬行。从连续主磁盘灯中可以清楚地看到存在磁盘I / O瓶颈（您也可以听到它）。如果我取消构建和关闭VS磁盘活动停止。重启VS，重新加载解决方案，然后重建，速度要快得多。下次是Unitl
我的想法是这是一个内存分页问题 - VS只是耗尽内存而O / S开始页面交换以尝试腾出空间但是VS要求的内容超过页面交换所能提供的，所以它会减慢到爬行。我想不出任何其他解释。
VS绝对不是RAD工具，不是吗？
答案 21 :(得分：1)
如果它是一个C ++项目，那么你应该使用预编译的头文件。这使编译时间产生巨大差异。不确定cl.exe到底在做什么（没有使用预编译的头文件），它似乎在最终到达正确的位置之前在所有错误的地方寻找批次的STL标头。这会为正在编译的每个.cpp文件添加整秒。不确定这是否是一个cl.exe错误，或VS2008中的某种STL问题。
答案 22 :(得分：1)
选择CPU时：L1缓存大小似乎对编译时间有很大影响。此外，通常最好有2个快速核心而不是4个慢速核心。 Visual Studio不会非常有效地使用额外的内核。 （我的基础是我对C ++编译器的经验，但对于C＃编译器来说也是如此。）
答案 23 :(得分：1)
Visual Studio 2005中有未记录的/ MP切换，请参阅http://lahsiv.net/blog/?p=40，这将基于文件而不是项目基础启用并行编译。这可以加快编译最后一个项目，或者，如果你编译一个项目。
答案 24 :(得分：1)
查看您正在构建的计算机，是否进行了最佳配置？
我们通过确保安装了正确的SATA过滤器驱动程序，将我们最大的C ++企业级产品的构建时间从 19小时下降到 16分钟。
微妙。
答案 25 :(得分：1)
您还可能想要检查循环项目引用。这对我来说只是一个问题。
那是：
项目A引用项目B
项目B参考项目C
项目C引用项目A
答案 26 :(得分：1)
Xoreax IB的一个更便宜的替代方案是使用我称之为超级文件构建的东西。它基本上是一个带有
的.cpp文件#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"
然后编译超级单元而不是单个模块。我们已经看到编译时间从10-15分钟到1-2分钟。您可能需要体验每个uber文件中有多少#includes有意义。取决于项目。也许你包括10个文件，可能是20个。
你支付一笔费用，所以要小心：
这是一种痛苦，但对于一个在新模块方面基本上是静态的项目，初始痛苦可能是值得的。在某些情况下，我看到这种方法胜过IB。
答案 27 :(得分：1)
如果这是一个Web应用程序，将批量生成设置为true可能会有所帮助，具体取决于方案。
<compilation defaultLanguage="c#" debug="true" batch="true" >
您可以在此处找到概述：http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx
答案 28 :(得分：0)
确定VS2008存在问题。因为我唯一做的就是安装VS2008以升级我用VS2005创建的项目。 我的解决方案中只有2个项目。它并不大。 使用VS2005编译：30秒 使用VS2008进行编译：5分钟
答案 29 :(得分：0)
我发现有一些东西可用于编写 C＃/.NET 版本：
将小项目合并到更大的项目中，因为构建解决方案的每个项目开销很大。 （如果需要，使用 nDepend 来控制跨层调用）
将所有项目构建到某个输出目录中，然后在所有项目引用上将“copy local”设置为false - 由于IO减少，这可能会导致大量加速。
转动病毒检查程序，看看它是否有很大差异;如果是这样，请找到faster virus checker，或从病毒检查程序扫描中排除“热门”文件夹
使用perforce监视器和sys内部工具来查看编译所花费的时间。
考虑使用ram磁盘放置输出目录。
考虑使用SSD
更多的内存有时会产生很大的影响 - （如果你通过移除一个小的ram来减慢机器内的ram，你可以通过添加更多来加快速度） 删除不需要的项目引用（您可能必须先删除不需要的“usings”）
考虑为最低域层使用依赖注入框架和接口，因此只有在接口更改时才需要重新编译所有内容 - 根据接口更改的频率，这可能不会获得太多收益。
答案 30 :(得分：0)
到目前为止已经提供了很好的建议（不是说下面没有其他好的建议，如果你遇到问题，我建议你阅读，这对我们有什么帮助）
仍然没有通过编译窃听，但每一点都有帮助。
我们还在测试在新解决方案中构建应用程序新领域的实践，根据需要导入最新的dll，当我们对它们感到满意时，将它们集成到更大的解决方案中。
我们也可以通过创建临时解决方案来对现有代码执行相同的操作，这些解决方案仅封装我们需要处理的区域，并在重新集成代码后将它们丢弃。我们需要权衡重新整合这些代码所需的时间，而不是让Rip Van Winkle在开发过程中快速重新编译时获得经验。
Orion确实在评论中提到仿制药也可能有戏剧性。从我的测试来看，似乎确实有最小的性能损失，但不足以确定 - 由于光盘活动，编译时间可能不一致。由于时间限制，我的测试没有包含与实时系统中出现的一样多的泛型或代码，因此可能会累积。我不会避免在它们应该被使用的地方使用泛型，只是为了编译时间性能答案 31 :(得分：0)
我发现以下有助于编译速度：重复编译（在内存中迭代开发）后，我会退出VS2008。然后进入项目目录并删除所有obj和bin文件夹，启动项目备份，然后我的编译时间恢复原状。这类似于VS2008中的Clean solution操作。
只是想确认这对那里的任何人是否有用。
答案 32 :(得分：0)
答案 33 :(得分：-1)
Visual Studio Studio性能下降......解决了！ 2014年9月24日，Uzma Abidi
今天我遇到了与性能有关的奇怪问题。我的Microsoft Visual Studio似乎花费太长时间来执行即使是最简单的操作。我用Google搜索并尝试了一些人们拥有的想法，例如禁用加载项或清除Visual Studio最近的项目列表，但这些建议似乎没有解决问题。我记得Windows SysInternals网站上有一个名为Process Monitor的工具，可以嗅探任何正在运行的程序的注册表和文件访问。在我看来，Visual Studio取决于某些东西，Process Monitor应该帮助我弄清楚它是什么。我下载了最新版本，在使用其显示过滤器稍微摆弄一下之后，运行它并且令我恐惧，我看到Visual Studio非常慢，因为它访问了C：\ Users \ krintoul \中的10,000多个文件夹大多数IDE操作中的AppData \ Local \ Microsoft \ WebSiteCache。我不确定为什么会有那么多文件夹，而且不确定Visual Studio正在使用它们，但在我将这些文件夹压缩并将它们移动到其他地方后，Visual Studio的性能得到了极大的提升。
Windows SysInternals网站还有许多其他有用的网络管理，安全性，系统信息等实用工具。看看这个。我相信你会找到有价值的东西。