问Visual Studio 2005上的编译速度非常慢

EN

我们的编译时间变得非常慢，在双核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那样的快速重新编译经验所获得的时间。