Visual Studio 2005上的编译速度非常慢
我们的编译时间变得非常慢，在双核2 2GHz、2G Ram机器上可能需要几分钟的20+时间。
这在很大程度上是由于我们的解决方案的规模已经增长到70+项目，以及VSS，当你有很多文件时，这本身就是一个瓶颈。(不幸的是，换掉VSS不是一个选项，所以我不希望这件事演变成VSS bash)
我们正在考虑合并项目。我们还在考虑使用多个解决方案来实现更大的关注点分离，并加快应用程序每个元素的编译时间。我可以预见，这将成为一个DLL地狱，因为我们试图保持同步。
我很想知道其他团队是如何处理这个伸缩问题的，当你的代码库达到临界值时，你会怎么做，以至于你浪费了半天的时间看着状态栏传递编译消息。
更新我忘了提一下这是一个C#解决方案。感谢所有C++的建议，但我已经有几年没有担心头文件了。
编辑：
到目前为止有帮助的好建议(并不是说下面没有其他好的建议，只是有帮助)
- 新的3 3GHz笔记本电脑-当在编译过程中从VSS (实际上是网络)编译
- 'Disconnecting‘时抱怨管理
- 禁用防病毒时，利用率下降的威力令人惊讶-我可能会让我们完全删除VS-VSS集成，并坚持使用VSS UI
仍然不是通过编译来破解，但每一点都是有帮助的。
Orion确实在一条评论中提到，泛型也可能有作用。从我的测试中，似乎有一个最小的性能影响，但不是足够高，以确保-编译时间可能是不一致的磁盘活动。由于时间的限制，我的测试没有包括像在实时系统中出现的那么多的泛型或代码，所以可能会累积。我不会避免在应该使用泛型的地方使用它们，只是为了提高编译时的性能
解决方法
我们正在测试在新的解决方案中构建新的应用程序区域的实践，根据需要导入最新的dlls，当我们对它们满意时，将它们集成到更大的解决方案中。
我们也可以通过创建临时解决方案来封装我们需要处理的区域，并在重新集成代码后将其丢弃，从而对现有代码执行相同的操作。我们需要权衡一下重新集成这段代码所需的时间，以及我们在开发过程中没有Rip Van Winkle那样的快速重新编译经验所获得的时间。
回答 32
Stack Overflow用户
发布于 2008-09-11 01:34:44
Chromium.org团队列出了accelerating the build的几个选项(在这一点上大约在页面的一半)：
按加速比降序排列的
：
- 安装Microsoft hotfix 935225.
- Install Microsoft hotfix 947315。
- 使用真正的多核处理器(即英特尔酷睿双核处理器2；而不是奔腾4 HT)。
- 使用3个并行构建。在Visual Studio2005中，您可以在工具>选项...中找到该选项。>项目和解决方案>构建并运行>针对.ilk、.pdb、.cc和.h文件的防病毒软件的最大并行项目数，并仅检查modify上的病毒。禁用扫描源代码所在的目录。不要做任何stupid.
- Store的事情，在第二个硬盘上构建Chromium代码。它不会真的加快构建速度，但至少当你进行gclient同步或build.
- Defragment你的硬盘regularly.
- Disable虚拟内存时，你的计算机将保持响应。
Stack Overflow用户
发布于 2011-07-08 23:18:35
我们在一个解决方案中有近100个项目，开发构建时间只有几秒钟:)
对于本地开发构建，我们创建了一个Visual Studio外接程序，它将Project references更改为DLL references，并卸载不需要的项目(当然还有一个切换回它们的选项)。
- 在
- 卸载我们当前未处理的项目并将所有项目引用更改为DLL后构建我们的整个解决方案
签入将所有引用从DLL更改回项目引用。
当我们一次只处理几个项目时，我们的构建现在只需要几秒钟。我们还可以调试其他项目，因为它链接到调试DLL。该工具通常需要10-30秒来进行大量更改，但您不必经常这样做。
更新2015年5月
我做的交易(在下面的评论中)是，如果它获得足够的兴趣，我将把插件发布到开源。4年后，它只有44票( Visual Studio现在有两个后续版本)，所以它目前是一个低优先级的项目。
Stack Overflow用户
发布于 2012-05-11 23:58:12
对于C# .NET版本，您可以使用.NET Demon。它是一个接管Visual Studio构建过程以使其更快的产品。
它通过分析您所做的更改来实现这一点，并且只构建您实际更改的项目，以及实际依赖于您所做更改的其他项目。这意味着如果您只更改内部代码，则只需要构建一个项目。
https://stackoverflow.com/questions/55517
复制相似问题
腾讯云开发者
