在Visual Studio 2005上非常慢的编译时间 [英] Very slow compile times on Visual Studio 2005

问题描述

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

很多原因是由于我们的解决方案的规模已经增长到70多个项目，以及VSS，这本身就是一个瓶颈，当你有很多文件。 （换出VSS不是一个不幸的选择，所以我不想让它下降到VSS bash）

我们正在寻找合并项目。我们还在寻找具有多个解决方案，以实现更大的关注点和更快的编译时间为应用程序的每个元素。

我有兴趣知道其他团队如何处理这个缩放问题，什么做

UPDATE $ b。如果您的代码库达到临界质量， $ b我忽略了这是一个C＃解决方案。感谢所有的C ++建议，但它已经过了几年，因为我不得不担心头。

编辑：

到目前为止已经帮助的好建议（不是说下面没有其他好的建议，只是有帮助）

• 新3GHz笔记本电脑 - 丢失利用的力量在管理时产生奇迹
  
• 在编译期间禁用反病毒
  
• 从VSS断开连接网络）在编译期间 - 我可能让我们删除VS-VSS集成，坚持使用VSS UI
  

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

Orion在评论中提到，泛型也可能有玩法。从我的测试，似乎有一个最小的性能命中，但不够高到足以确定 - 编译时间可能不一致，由于光盘活动。由于时间限制，我的测试没有包括尽可能多的泛型或者代码，因为会出现在实时系统，所以可能积累。我不会避免在应用程序中使用泛型，只是为了编译时的性能。

WORKAROUND

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

我们也可以通过创建临时解决方案来对现有代码进行相同的操作，这些解决方案只是封装了我们需要处理的区域，并在重新整合代码后将它们丢弃。我们需要加倍重新整合这段代码所花费的时间，而不是像Rip Van Winkle那样在开发过程中快速重新编译的经验。

解决方案

Chromium.org小组列出了加速构建（此时大约在页面的中间位置）：

按加速顺序递减顺序： / p>

• 安装Microsoft修补程序 935225 。


• 安装Microsoft修补程序 947315 。


• 使用真正的多核处理器（即Intel Core Duo 2;而不是Pentium 4 HT）。


• 使用3个并行版本。在Visual Studio 2005中，您可以在工具>选项...>项目和解决方案>构建和运行>并行项目构建的最大数量中找到该选项。


• 禁用.ilk，.pdb，.cc，.h文件的防病毒软件，并仅在修改上检查病毒。禁用扫描源所在的目录。不要做任何蠢事。


• 在第二个硬盘驱动器上存储和构建Chromium代码。


• 定期对您的硬盘进行碎片整理。


• 停用虚拟内存。

We are getting very slow compile times, which can take upwards of 20+ minutes on dual core 2GHz, 2G Ram machines.

A lot of this is due to the size of our solution which has grown to 70+ projects, as well as VSS which is a bottle neck in itself when you have a lot of files. (swapping out VSS is not an option unfortunately, so I don't want this to descend into a VSS bash)

We are looking at merging projects. We are also looking at having multiple solutions to achieve greater separation of concerns and quicker compile times for each element of the application. This I can see will become a DLL hell as we try to keep things in synch.

I am interested to know how other teams have dealt with this scaling issue, what do you do when your code base reaches a critical mass that you are wasting half the day watching the status bar deliver compile messages.

UPDATE I neglected to mention this is a C# solution. Thanks for all the C++ suggestions, but it's been a few years since I've had to worry about headers.

EDIT:

Nice suggestions that have helped so far (not saying there aren't other nice suggestions below, just what has helped)

• New 3GHz laptop - the power of lost utilization works wonders when whinging to management
• Disable Anti Virus during compile
• 'Disconnecting' from VSS (actually the network) during compile - I may get us to remove VS-VSS integration altogether and stick to using the VSS UI

Still not rip-snorting through a compile, but every bit helps.

Orion did mention in a comment that generics may have a play also. From my tests there does appear to be a minimal performance hit, but not high enough to sure - compile times can be inconsistent due to disc activity. Due to time limitations, my tests didn't include as many Generics, or as much code, as would appear in live system, so that may accumulate. I wouldn't avoid using generics where they are supposed to be used, just for compile time performance

WORKAROUND

We are testing the practice of building new areas of the application in new solutions, importing in the latest dlls as required, them integrating them into the larger solution when we are happy with them.

We may also do them same to existing code by creating temporary solutions that just encapsulate the areas we need to work on, and throwing them away after reintegrating the code. We need to weigh up the time it will take to reintegrate this code against the time we gain by not having Rip Van Winkle like experiences with rapid recompiling during development.

解决方案

The Chromium.org team listed several options for accelerating the build (at this point about half-way down the page):

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.

这篇关于在Visual Studio 2005上非常慢的编译时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！