Very slow compile times on Visual Studio 2005我们的编译时间非常慢，在双核2GHz，2G Ram机器上可能需要20多分钟。 这很大程度上是由于我们的解决方案的规模已经发展到70多个项目，以及VSS，当你拥有大量文件时，它本身就是瓶颈。 (不幸的是，交换VSS不是一个选项，所以我不希望这个进入VSS bash) 我们正在考虑合并项目。我们还在寻找多种解决方案，以便为应用程序的每个元素实现更大的关注点分离和更快的编译时间。我可以看到这将成为一个DLL地狱，因为我们试图保持同步。 我很想知道其他团队如何处理这个扩展问题，当你的代码库达到一个临界质量时你会怎么做，你正在看着状态栏传递编译消息的一半时间。
UPDATE 编辑： 到目前为止有很好的建议(不是说下面没有其他好的建议，只是帮助了什么)
仍然没有通过编译扯皮，但每一点都有帮助。 Orion在评论中确实提到仿制药也可能有一个游戏。从我的测试来看，似乎确实有最小的性能损失，但不足以确定 - 由于光盘活动，编译时间可能不一致。由于时间限制，我的测试没有包含与实时系统中出现的一样多的泛型或代码，因此可能会累积。我不会避免在它们应该被使用的地方使用泛型，只是为了编译时的性能 替代方法 我们正在测试在新解决方案中构建应用程序新领域的实践，根据需要导入最新的dll，当我们对它们感到满意时，将它们集成到更大的解决方案中。 我们也可以通过创建临时解决方案来对现有代码执行相同的操作，这些解决方案仅封装我们需要处理的区域，并在重新集成代码后将它们丢弃。我们需要权衡重新整合这些代码所需的时间与我们获得的时间，因为没有Rip Van Winkle喜欢在开发过程中快速重新编译的经验。 Chromium.org团队列出了几个加速构建的选项(此时大约是页面的一半)：
我们在一个解决方案中有近100个项目，开发时间只有几秒钟:)
对于本地开发版本，我们创建了一个Visual Studio Addin，它将
我们的构建现在只需几秒钟，我们一次只处理几个项目。我们还可以在链接到调试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驱动器不容低估。构建显着更快，加上其他所有内容，如显示文档，使用文件浏览器显然更快。通过加快代码构建运行周期，可以大大提高生产力。 考虑到公司在开发人员工资上花费了多少钱，他们可以浪费多少钱来为他们配备与接待员使用相同的PC。 对于C＃.NET构建，您可以使用.NET Demon。它是一种接管Visual Studio构建过程以使其更快的产品。 它通过分析您所做的更改来完成此操作，并仅构建您实际更改的项目，以及实际依赖您所做更改的其他项目。这意味着如果您只更改内部代码，则只需要构建一个项目。 关闭防病毒软件。它增加了编译时间。 使用分布式编译。 Xoreax IncrediBuild可以将编译时间缩短到几分钟。 我在一个庞大的C C ++解决方案中使用它，通常需要5-6个小时来编译。 IncrediBuild帮助将这个时间减少到15分钟。 有关将Visual Studio编译时间缩短到几秒的说明 遗憾的是，Visual Studio不够智能，无法将程序集的界面更改与无关紧要的代码体更改区分开来。这一事实与大型交织解决方案相结合，有时可以在每次更改单行代码时创建一个完美的不必要的"完整构建"风暴。 克服此问题的策略是禁用自动引用树构建。要执行此操作，请使用"Configuration Manager"(构建/配置管理器...然后在"活动解决方案配置"下拉列表中选择"新建")以创建一个名为"ManualCompile"的新构建配置，该配置从Debug配置进行复制，但是不选中"创建新项目配置"复选框。在这个新的构建配置中，取消选中每个项目，以便它们不会自动构建。点击"关闭"保存此配置。此新构建配置将添加到您的解决方案文件中。 您可以通过IDE屏幕顶部的构建配置下拉列表(通常显示"Debug"或"Release")来从一个构建配置切换到另一个构建配置。实际上，这个新的ManualCompile构建配置将使"构建解决方案"或"重建解决方案"的构建菜单选项无效。因此，当您处于ManualCompile模式时，必须手动构建要修改的每个项目，这可以通过在解决方案资源管理器中右键单击每个受影响的项目，然后选择"构建"或"重建"来完成。你应该看到你的整体编译时间现在只有几秒钟。 要使此策略起作用，必须使AssemblyInfo和GlobalAssemblyInfo文件中的VersionNumber在开发人员的计算机上保持静态(当然不是在发布版本期间)，并且不要对DLL进行签名。 使用此ManualCompile策略的潜在风险是开发人员可能忘记编译所需的项目，并且当他们启动调试器时，他们会得到意外的结果(无法附加调试器，找不到文件等)。为避免这种情况，最好使用"Debug"构建配置来编译更大的编码工作，并且仅在单元测试期间使用ManualCompile构建配置或进行范围有限的快速更改。 如果这是C或C ++，并且您没有使用预编译的头文件，那么您应该这样做。 确保您的引用是Project引用，而不是直接引用到库输出目录中的DLL。 此外，将这些设置为不在本地复制，除非绝对必要(主EXE项目)。 我们的主要解决方案中有80多个项目，需要大约4到6分钟才能构建，具体取决于开发人员正在使用哪种机器。我们认为这太长了：对于每一次测试，它都会真正吞噬你的FTE。 那么如何加快构建时间呢？正如您似乎已经知道的那样，真正损害构建时间的项目数量。当然，我们不想摆脱所有项目，只需将所有源文件合并为一个。但是我们有一些项目可以合并：由于解决方案中的每个"知识库项目"都有自己的单元测试项目，我们只需将所有单元测试项目合并为一个全局单元测试项目。这减少了大约12个项目的项目数量，并以某种方式节省了40％的时间来构建整个解决方案。 我们正在考虑另一种解决方案。 您是否也尝试使用新项目设置新的(第二)解决方案？第二个解决方案应该只使用解决方案文件夹合并所有文因为您可能会惊讶地看到新解决方案的构建时间 - 只需一个项目。 但是，使用两种不同的解决方案需要仔细考虑。开发人员可能倾向于在第二个解决方案中实际工作，而完全忽略第一个解决方案。由于70多个项目的第一个解决方案将是处理对象层次结构的解决方案，因此这应该是构建服务器应运行所有单元测试的解决方案。因此，Continous Integration的服务器必须是第一个项目/解决方案。你必须维护你的对象层次结构。 只有一个项目的第二个解决方案(将更快地构建)将是所有开发人员将完成测试和调试的项目。你必须照顾他们看看构建服务器！如果有什么破坏必须修复。
我原来在这里发布了这个回复： 如果您使用的是Visual Studio 2008，则可以使用/ MP标志进行编译，以并行构建单个项目。我已经读过，这也是Visual Studio 2005中的一个未记录的功能，但从未尝试过。 您可以使用/ M标志并行构建多个项目，但这通常已设置为计算机上可用核心的数量，但这仅适用于我认为的VC ++。 我注意到这个问题已经很久了，但今天这个话题仍然很有意思。同样的问题最近让我感到困惑，最能提高构建性能的两件事是：(1)使用专用(和快速)磁盘进行编译;(2)对所有项目使用相同的输出文件夹，并在项目中将CopyLocal设置为False引用。 一些额外的资源：
在花钱购买更快的硬盘之前，尝试完全在RAM磁盘上构建项目(假设你有备用的RAM)。您可以在网上找到各种免费的RAM磁盘驱动程序。您将找不到比RAM磁盘更快的任何物理驱动器，包括SSD。 在我的情况下，使用RAM磁盘，在带有Incredibuild的7200 RPM SATA驱动器上花费5分钟构建6核i7的项目仅减少了大约15秒。考虑到需要重新复制到永久存储和丢失工作的可能性，15秒不足以激励使用RAM磁盘，并且可能没有太多动力在高RPM或SSD驱动器上花费数百美元。 小增益可能表明构建受CPU限制或Windows文件缓存相当有效，但由于两个测试都是从未缓存文件的状态完成的，因此我非常倾向于CPU绑定编译。 根据您编制的实际代码，您的里程可能会有所不同 - 所以请不要犹豫，进行测试。 一些分析工具：
tools-> options-> VC ++项目设置 - > Build Timing = Yes
将
使用 这将通过消除依赖性和性能损害来帮助您优化编译器性能。 完成构建后，构建目录有多大？如果您坚持使用默认设置，那么您构建的每个程序集都会将其依赖项的所有DLL及其依赖项的依赖项等复制到其bin目录中。在我以前的工作中使用~40个项目的解决方案时，我的同事发现，到目前为止，构建过程中最昂贵的部分是反复复制这些程序集，并且一个构建可以生成相同DLL的千兆字节副本。再次。 以下是NDepend的作者Patrick Smacchia的一些有用的建议，他认为应该和不应该是单独的程序集： http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/ 基本上有两种方法可以解决这个问题，两者都有缺点。一个是减少组件数量，这显然是很多工作。另一个是重构您的构建目录，以便合并所有bin文件夹，并且项目不会复制其依赖项的DLL - 它们不需要，因为它们都已在同一目录中。这大大减少了在构建期间创建和复制的文件数量，但是设置起来可能很困难，并且可能会使您难以仅提取特定可执行文件所需的DLL以进行打包。 关闭VSS集成。您可能没有选择使用它，但DLL会被"意外"重命名... 绝对检查您的预编译标头设置。 Bruce Dawson的指南有点陈旧，但仍然非常好 - 请查看：http：//www.cygnus-software.com/papers/precompiledheaders.html 禁用源目录上的文件系统索引(特别是obj目录，如果您希望源代码可搜索) 也许采用一些常用函数并创建一些库，这样就不会为多个项目反复编译相同的源代码。 如果您担心混合的不同版本的DLL，请使用静态库。 我有一个项目，有120或更多的exes，libs和dll，需要相当长的时间来构建。我使用一个批处理文件树，从一个主批处理文件调用make文件。我在过去使用增量(或者是气质)标题时遇到了奇怪的问题，所以我现在就避开它们。我不经常做一个完整的构建，并且通常在我散步一小时的时候离开它(所以我只能猜测它需要大约半小时)。所以我理解为什么这对于工作和测试是行不通的。 对于工作和测试，我为每个应用程序(或模块或库)提供了另一组批处理文件，这些文件也具有所有调试设置 - 但这些仍然调用相同的make文件。我可能会不时地关闭DEBUG并决定构建或制作或者我是否还要构建模块可能依赖的库，依此类推。 批处理文件还将完成的结果复制到(或多个)测试文件夹中。根据设置，这在几秒到一分钟内完成(而不是半小时)。 我使用不同的IDE(Zeus)，因为我喜欢控制像.rc文件这样的东西，实际上更喜欢从命令行编译，即使我使用的是MS编译器。 如果有兴趣的话，很高兴发布这个批处理文件的例子。 Xoreax IB的一个更便宜的替代品是使用我称之为超级文件构建的东西。它基本上是一个.cpp文件
然后编译超级单元而不是单个模块。我们已经看到编译时间从10-15分钟到1-2分钟。您可能需要体验每个uber文件中有多少#includes有意义。取决于项目。等等。也许你包括10个文件，也许20个。 你支付一笔费用，所以要小心： 这是一种痛苦，但对于一个在新模块方面基本上是静态的项目，初始痛苦可能是值得的。在某些情况下，我看到这种方法击败了IB。 您还可能想要检查循环项目引用。这对我来说只是一个问题。 那是： 项目A参考项目B. 项目B参考项目C. 项目C参考项目A. 如果这是一个Web应用程序，将批量生成设置为true可能会有所帮助，具体取决于方案。
你可以在这里找到一个概述：http：//weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx 如果它是一个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的双核英特尔笔记本电脑上运行它，关闭了防病毒软件。编译解决方案通常非常灵活，但如果我一直在调试，后续重新编译通常会慢下来爬行。从连续主磁盘灯中可以清楚地看到存在磁盘I / O瓶颈(您也可以听到它)。如果我取消构建和关闭VS磁盘活动停止。重启VS，重新加载解决方案，然后重建，速度要快得多。 Unitl下次 我的想法是，这是一个内存分页问题 - VS只是耗尽内存而O / S开始页面交换以尝试腾出空间，但VS要求的不仅仅是页面交换可以提供，所以它会慢下来爬行。我想不出任何其他解释。 VS绝对不是RAD工具，是吗？ 您的公司是否恰巧使用Entrust进行PKI /加密解决方案？事实证明，我们在一个用C＃构建的相当大的网站上拥有糟糕的构建性能，在Rebuild-All上花了7分多钟。 我的机器是i7-3770，配备16GB内存和512GB SSD，因此性能不应该那么糟糕。我注意到在构建相同代码库的旧辅助计算机上，我的构建时间非常快。所以我在两台机器上启动了ProcMon，分析了构建，并对结果进行了比较。 瞧，性能低下的机器有一个区别 - 在堆栈跟踪中引用了Entrust.dll。使用这个新获得的信息，我继续搜索StackOverflow并发现：MSBUILD(VS2010)在某些机器上非常慢。根据公认的答案，问题在于Entrust处理程序正在处理.NET证书检查而不是本机Microsoft处理程序。还建议Entrust v10解决Entrust 9中普遍存在的这个问题。 我目前已将其卸载，我的构建时间暴跌至24秒。 YYMV包含您当前正在构建的项目数量，可能无法直接解决您要查询的扩展问题。如果我可以提供修复而不需要卸载软件，我将对此响应发布编辑。 到目前为止提供了很好的建议(不是说下面没有其他好的建议，如果你有问题，我建议你阅读，这对我们有什么帮助)
仍然没有通过编译扯皮，但每一点都有帮助。 我们还测试了在新解决方案中构建应用程序新领域的实践，根据需要导入最新的dll，当我们对它们满意时，将它们集成到更大的解决方案中。 我们也可以通过创建临时解决方案来对现有代码执行相同的操作，这些解决方案仅封装我们需要处理的区域，并在重新集成代码后将它们丢弃。我们需要权衡重新整合这些代码所需的时间与我们获得的时间，因为没有Rip Van Winkle喜欢在开发过程中快速重新编译的经验。 Orion在评论中确实提到仿制药也可能有一个游戏。从我的测试来看，似乎确实有最小的性能损失，但不足以确定 - 由于光盘活动，编译时间可能不一致。由于时间限制，我的测试没有包含与实时系统中出现的一样多的泛型或代码，因此可能会累积。我不会避免在它们应该被使用的地方使用泛型，只是为了编译时的性能 我发现有一些东西可用于编写C＃/ .NET版本：
我发现以下有助于编译速度：重复编译(在内存中迭代开发)后，我会退出VS2008。然后进入项目目录并删除所有 只是想确认这对那里的任何人是否有用。 我在这里找到了我的修复：http：//blogs.msdn.com/b/vsdteam/archive/2006/09/15/756400.aspx
确定VS2008存在问题。因为我唯一做的就是安装VS2008以升级我用VS2005创建的项目。
慢Visual Studio性能......解决了！ 我今天遇到了与性能有关的奇怪问题。我的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网站还有许多其他有用的实用程序，用于网络管理，安全性，系统信息等。看看这个。我相信你会找到有价值的东西。 |
