C# Visual Studio 2005 上的编译时间很慢

Very slow compile times on Visual Studio 2005

提问by johnc

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

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

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)

这在很大程度上是由于我们的解决方案的规模已经增长到 70 多个项目，以及 VSS，当您拥有大量文件时，VSS 本身就是一个瓶颈。（不幸的是，换出 VSS 不是一种选择，所以我不希望这陷入 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.

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

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.

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

UPDATEI 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.

更新我忽略了这是一个 C# 解决方案。感谢所有的 C++ 建议，但我已经好几年没有担心头文件了。

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

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

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

仍然没有通过编译进行 rip-snorting，但每一点都有帮助。

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

Orion 在评论中确实提到泛型也可能有作用。从我的测试来看，性能影响似乎很小，但不足以确定 - 由于磁盘活动，编译时间可能不一致。由于时间限制，我的测试没有包含在实时系统中出现的那么多泛型或那么多代码，因此可能会累积。我不会避免在应该使用泛型的地方使用它们，只是为了编译时性能

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.

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

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.

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

采纳答案by Nate

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

Chromium.org 团队列出了几个加速构建的选项（此时大约在页面的一半）：

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.

按加速递减顺序：

• 安装 Microsoft 修补程序935225。
• 安装 Microsoft 修补程序947315。
• 使用真正的多核处理器（即 Intel Core Duo 2；而不是 Pentium 4 HT）。
• 使用 3 个并行构建。在 Visual Studio 2005 中，您将在“工具”>“选项...”>“项目和解决方案”>“构建和运行”>“并行项目构建的最大数量”中找到该选项。
• 禁用 .ilk、.pdb、.cc、.h 文件的防病毒软件，仅在修改时检查病毒。禁用扫描源所在的目录。不要做傻事。
• 在第二个硬盘驱动器上存储和构建 Chromium 代码。它不会真正加快构建速度，但至少当您执行 gclient 同步或构建时，您的计算机将保持响应。
• 定期对硬盘进行碎片整理。
• 禁用虚拟内存。

回答by aku

Use distributed compilation. Xoreax IncrediBuildcan cut compilation time down to few minutes.

使用分布式编译。Xoreax IncrediBuild可以将编译时间缩短到几分钟。

I've used it on a huge C\C++ solution which usually takes 5-6 hours to compile. IncrediBuild helped to reduce this time to 15 minutes.

我在一个巨大的 C\C++ 解决方案上使用了它，通常需要 5-6 个小时来编译。IncrediBuild 帮助将这段时间减少到 15 分钟。

回答by Ed S.

I posted this response originally here: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473You can find many other helpful hints on that page.

我最初在此处发布了此回复：https: //stackoverflow.com/questions/8440/visual-studio-optimizations#8473您可以在该页面上找到许多其他有用的提示。

If you are using Visual Studio 2008, you can compile using the /MP flag to build a single project in parallel. I have read that this is also an undocumented feature in Visual Studio 2005, but have never tried myself.

如果您使用的是 Visual Studio 2008，则可以使用 /MP 标志进行编译以并行构建单个项目。我已经读到这也是 Visual Studio 2005 中未记录的功能，但我自己从未尝试过。

You can build multiple projects in parallel by using the /M flag, but this is usually already set to the number of available cores on the machine, though this only applies to VC++ I believe.

您可以使用 /M 标志并行构建多个项目，但这通常已经设置为机器上可用内核的数量，尽管我相信这仅适用于 VC++。

回答by Adam Pierce

Perhaps take some common functions and make some libraries, that way the same sources are not being compiled over and over again for multiple projects.

也许采用一些常用函数并制作一些库，这样就不会为多个项目一遍又一遍地编译相同的源代码。

If you are worried about different versions of DLLs getting mixed up, use static libraries.

如果您担心不同版本的 DLL 会混淆，请使用静态库。

回答by Kristopher Johnson

If this is C or C++, and you're not using precompiled headers, you should be.

如果这是 C 或 C++，并且您没有使用预编译头文件，那么您应该使用。

回答by Daniel Auger

If this is a web app, setting batch build to true can help depending on the scenario.

如果这是一个 Web 应用程序，根据场景将批处理构建设置为 true 会有所帮助。

<compilation defaultLanguage="c#" debug="true" batch="true" >  

You can find an overview here: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

您可以在此处找到概述：http: //weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

回答by Shog9

Turn off VSS integration. You may not have a choice in using it, but DLLs get "accidentally" renamed all the time...

关闭 VSS 集成。您可能没有选择使用它，但 DLL 总是“意外”重命名......

And definitely check your pre-compiled header settings. Bruce Dawson's guide is a bit old, but still verygood - check it out: http://www.cygnus-software.com/papers/precompiledheaders.html

并且一定要检查您的预编译头设置。布鲁斯·道森的指导是有点老了，但还是很不错的-检查出来：http://www.cygnus-software.com/papers/precompiledheaders.html

回答by David L Morris

I have a project which has 120 or more exes, libs and dlls and takes a considerable time to build. I use a tree of batch files that call make files from one master batch file. I have had problems with odd things from incremental (or was it temperamental) headers in the past so I avoid them now. I do a full build infrequently, and usually leave it to the end of the day while I go for a walk for an hour (so I can only guess it takes about half an hour). So I understand why that is unworkable for working and testing.

我有一个项目，它有 120 个或更多的 exe、libs 和 dll，并且需要相当长的时间来构建。我使用一棵批处理文件树，从一个主批处理文件调用 make 文件。过去，我遇到过增量（或者是喜怒无常的）标题的奇怪问题，所以我现在避免使用它们。我很少做一个完整的构建，通常把它留到一天结束，然后我去散步一个小时（所以我只能猜测大约需要半小时）。所以我理解为什么这对于工作和测试是行不通的。

For working and testing I have another set of batch files for each app (or module or library) which also have all the debugging settings in place -- but these still call the same make files. I may switch DEBUG on of off from time to time and also decide on builds or makes or if I want to also build libs that the module may depend on, and so on.

为了工作和测试，我为每个应用程序（或模块或库）准备了另一组批处理文件，这些文件也有所有的调试设置——但它们仍然调用相同的 make 文件。我可能会不时打开或关闭 DEBUG，并决定构建或制造，或者我是否还想构建模块可能依赖的库，等等。

The batch file also copies the completed result into the (or several) test folders. Depending of the settings this completes in several seconds to a minute (as opposed to say half an hour).

批处理文件还将完成的结果复制到（或多个）测试文件夹中。根据设置，这会在几秒到一分钟内完成（而不是半小时）。

I used a different IDE (Zeus) as I like to have control over things like .rc files, and actually prefer to compile from the command line, even though I am using MS compliers.

我使用了不同的 IDE (Zeus)，因为我喜欢控制 .rc 文件之类的东西，实际上更喜欢从命令行编译，即使我使用的是 MS 编译器。

Happy to post an example of this batch file if anyone is interested.

如果有人感兴趣，很高兴发布此批处理文件的示例。

回答by Mark

One cheaper alternative to Xoreax IB is the use of what I call uber-file builds. It's basically a .cpp file that has

Xoreax IB 的一种更便宜的替代方案是使用我所说的超级文件构建。它基本上是一个 .cpp 文件，具有

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

Then you compile the uber units instead of the individual modules. We've seen compile times from from 10-15 minutes down to 1-2 minutes. You might have to experiemnt with how many #includes per uber file make sense. Depends on the projects. etc. Maybe you include 10 files, maybe 20.

然后编译超级单元而不是单个模块。我们已经看到编译时间从 10-15 分钟缩短到 1-2 分钟。您可能需要体验每个 uber 文件有多少#includes 有意义。取决于项目。等等。也许你包含 10 个文件，也许 20 个。

You pay a cost so beware:

您需要支付费用，因此请注意：

1. You can't right click a file and say "compile..." as you have to exclude the individual cpp files from the build and include only the uber cpp files
2. You have to be careful of static global variable conflicts.
3. When you add new modules, you have to keep the uber files up to date

1. 您不能右键单击文件并说“编译...”，因为您必须从构建中排除单个 cpp 文件并仅包含 uber cpp 文件
2. 您必须小心静态全局变量冲突。
3. 添加新模块时，您必须保持 uber 文件是最新的

It's kind of a pain, but for a project that is largely static in terms of new modules, the intial pain might be worth it. I've seen this method beat IB in some cases.

这有点痛苦，但对于一个在新模块方面基本上是静态的项目，最初的痛苦可能是值得的。我已经看到这种方法在某些情况下击败了 IB。

回答by Bramha Ghosh

You also may want to check for circular project references. It was an issue for me once.

您可能还想检查循环项目引用。这对我来说曾经是一个问题。

That is:

那是：

Project A references Project B

项目 A 引用项目 B

Project B references Project C

项目 B 参考项目 C

Project C references Project A

项目 C 引用项目 A