c# - Visual Studio 2005 上的编译时间非常慢

Question

我们的编译时间变得非常慢，在双核 2GHz、2G Ram 机器上可能需要超过 20 分钟。

这在很大程度上是由于我们的解决方案规模已增长到 70 多个项目，以及当您有大量文件时 VSS 本身就是一个瓶颈。 (不幸的是，换掉 VSS 不是一个选项，所以我不希望它变成 VSS bash)

我们正在考虑合并项目。我们也在寻找多种解决方案，以实现更大程度的关注点分离和更快的应用程序每个元素的编译时间。当我们试图保持同步时，我可以看到这将变成一个 DLL hell 。

我很想知道其他团队是如何处理这个扩展问题的，当你的代码库达到临界质量而你浪费了半天时间看状态栏传递编译消息时，你会怎么做。

更新我没有提到这是一个 C# 解决方案。感谢所有 C++ 建议，但自从我不得不担心头文件以来已经有几年了。

编辑:

到目前为止有用的好建议(并不是说下面没有其他好的建议，只是有帮助)

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

仍然没有通过编译，但每一点都有帮助。

Orion 在评论中确实提到泛型也可能发挥作用。从我的测试来看，似乎确实对性能造成了最小的影响，但还不足以确定——由于光盘事件，编译时间可能会不一致。由于时间限制，我的测试没有包含尽可能多的泛型，也没有像在实时系统中出现的那样多的代码，因此可能会累积。我不会避免在应该使用泛型的地方使用泛型，只是为了编译时性能

解决方法

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

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

Answer 1

Chromium.org 团队为 accelerating the build 列出了几个选项(此时大约在页面的一半处):

In decreasing order of speedup:

• Install Microsoft hotfix 935225.
• Install Microsoft hotfix 947315.
• Use a true multicore processor (ie. an Intel Core Duo 2; not a Pentium 4 HT).
• Use 3 parallel builds. In Visual Studio 2005, you will find the option in Tools > Options... > Projects and Solutions > Build and Run > maximum number of parallel project builds.
• Disable your anti-virus software for .ilk, .pdb, .cc, .h files and only check for viruses on modify. Disable scanning the directory where your sources reside. Don't do anything stupid.
• Store and build the Chromium code on a second hard drive. It won't really speed up the build but at least your computer will stay responsive when you do gclient sync or a build.
• Defragment your hard drive regularly.
• Disable virtual memory.