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

https://stackoverflow.com/questions/55517

09-06-2019
|

题

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

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

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

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

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

编辑：

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

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

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

Orion 在评论中确实提到仿制药也可能发挥作用。从我的测试来看，性能确实受到了最小的影响，但还不够高，无法确定 - 由于光盘活动，编译时间可能会不一致。由于时间限制，我的测试没有包含与实时系统中一样多的泛型或代码，因此可能会累积。我不会避免在应该使用泛型的地方使用泛型，只是为了编译时性能

解决方法

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

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

解决方案

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

按加速比降序排列：

安装微软修补程序 935225.

安装微软修补程序 947315.

使用真正的多核处理器（即英特尔酷睿双核 2；不是 Pentium 4 HT）。

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

禁用 .ilk、.pdb、.cc、.h 文件的防病毒软件，仅检查以下文件上的病毒调整. 。禁用扫描源所在的目录。不要做任何愚蠢的事情。

在第二个硬盘上存储和构建 Chromium 代码。它不会真正加快构建速度，但至少当您进行 gclient 同步或构建时，您的计算机将保持响应。

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

禁用虚拟内存。

其他提示

我们在一个解决方案中拥有近 100 个项目，开发构建时间仅为几秒:)

对于本地开发构建，我们创建了一个可以更改的 Visual Studio Addin Project references 到 DLL references 并卸载不需要的项目（当然还有将它们切换回来的选项）。

构建我们的整个解决方案一次
卸载我们当前未处理的项目，并将所有项目引用更改为 DLL 引用。
在签入之前，将所有引用从 DLL 更改回项目引用。

当我们一次只处理几个项目时，我们的构建现在只需要几秒钟。我们仍然可以调试其他项目，因为它链接到调试 DLL。该工具通常需要 10-30 秒才能进行大量更改，但您不必经常这样做。

2015 年 5 月更新

我达成的协议（在下面的评论中）是我将插件发布到开源如果它得到了足够的兴趣。4 年后，它只有 44 票（Visual Studio 现在有两个后续版本），因此它目前是一个低优先级项目。

我在一个包含 21 个项目和 1/2 百万 LOC 的解决方案中遇到了类似的问题。最大的区别是获得更快的硬盘。从性能监视器中“平均”。“磁盘队列”在笔记本电脑上会显着上升，表明硬盘驱动器是瓶颈。

这是总重建时间的一些数据......

1) 笔记本电脑，Core 2 Duo 2GHz，5400 RPM 驱动器（不确定缓存。是标准的戴尔灵越）。

重建时间 = 112 秒。

2) 台式机（标准版），Core 2 Duo 2.3Ghz，单 7200RPM 驱动器 8MB 缓存。

重建时间 = 72 秒。

3) 台式机 Core 2 Duo 3Ghz，单 10000 RPM WD Raptor

重建时间 = 39 秒。

10,000 RPM 驱动器的作用不可低估。构建速度明显更快，而且其他一切（例如显示文档）、使用文件资源管理器的速度也明显更快。通过加快代码构建运行周期，极大地提高了生产力。

考虑到公司在开发人员工资上的支出 疯狂的 他们可以浪费多少钱来为他们配备与接待员使用的相同的电脑。

对于 C# .NET 构建，您可以使用 .NET恶魔. 。它是一款接管 Visual Studio 构建过程并使其速度更快的产品。

它通过分析您所做的更改来实现此目的，并且仅构建您实际更改的项目以及实际依赖于您所做的更改的其他项目。这意味着如果您只更改内部代码，则只需要构建一个项目。

关闭防病毒软件。它增加了编译时间。

使用分布式编译。奥雷克斯 IncrediBuild 可以将编译时间缩短到几分钟。

我已经在一个巨大的 C\C++ 解决方案上使用了它，该解决方案通常需要 5-6 小时来编译。IncrediBuild 帮助将此时间缩短至 15 分钟。

将 Visual Studio 编译时间缩短至几秒的说明

遗憾的是，Visual Studio 不够智能，无法区分程序集的界面更改和无关紧要的代码体更改。这一事实，当与大型相互交织的解决方案相结合时，有时几乎每次更改一行代码时都会产生一场不需要的“完整构建”的完美风暴。

克服这个问题的策略是禁用自动引用树构建。为此，请使用“配置管理器”（构建/配置管理器...然后在活动解决方案配置下拉列表中选择“新建”）创建一个名为“ManualCompile”的新构建配置，该配置从调试配置复制，但执行以下操作：不选中“创建新项目配置”复选框。在这个新的构建配置中，取消选中每个项目，这样它们就不会自动构建。点击“关闭”保存此配置。这个新的构建配置将添加到您的解决方案文件中。

您可以通过 IDE 屏幕顶部的构建配置下拉列表（通常显示“调试”或“发布”）从一种构建配置切换到另一种构建配置。实际上，这个新的 ManualCompile 构建配置将使“构建”菜单选项变得无用：“构建解决方案”或“重建解决方案”。因此，当您处于手动编译模式时，您必须手动构建您正在修改的每个项目，这可以通过在解决方案资源管理器中右键单击每个受影响的项目，然后选择“构建”或“重建”来完成。您应该看到您的总体编译时间现在只有几秒钟。

要使此策略发挥作用，AssemblyInfo 和 GlobalAssemblyInfo 文件中的 VersionNumber 必须在开发人员的计算机上保持静态（当然不是在发布版本期间），并且您不对 DLL 进行签名。

使用此 ManualCompile 策略的一个潜在风险是，开发人员可能会忘记编译所需的项目，并且当他们启动调试器时，会得到意外的结果（无法附加调试器、找不到文件等）。为了避免这种情况，最好使用“调试”构建配置来编译更大的编码工作，并且仅在单元测试期间或进行有限范围的快速更改时使用 ManualCompile 构建配置。

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

我们的主要解决方案中有 80 多个项目，根据开发人员使用的机器类型，构建大约需要 4 到 6 分钟。我们认为这太长了：每一次测试都会消耗你的 FTE。

那么如何获得更快的构建时间呢？正如您似乎已经知道的那样，真正影响构建时间的是项目数量。当然，我们不想放弃所有项目，而只是将所有源文件放入一个项目中。但我们有一些可以合并的项目：由于解决方案中的每个“存储库项目”都有自己的单元测试项目，因此我们只需将所有单元测试项目合并为一个全局单元测试项目。这减少了大约 12 个项目的数量，并在某种程度上节省了 40% 的构建整个解决方案的时间。

不过，我们正在考虑另一种解决方案。

您是否也尝试过使用新项目设置新的（第二个）解决方案？第二个解决方案应该简单地使用解决方案文件夹合并所有文件。因为您可能会惊讶地发现只有一个项目的新解决方案的构建时间。

然而，使用两种不同的解决方案需要仔细考虑。开发人员可能倾向于实际使用第二个解决方案，而完全忽略第一个解决方案。由于包含 70 多个项目的第一个解决方案将是负责对象层次结构的解决方案，因此这应该是您的构建服务器运行所有单元测试的解决方案。因此，持续集成的服务器必须是第一个项目/解决方案。您必须维护您的对象层次结构，对吧。

只有一个项目的第二种解决方案（构建速度会快得多）将是由所有开发人员完成测试和调试的项目。不过，您必须在构建服务器上照顾它们！如果有任何损坏，则必须修复。

确保您的引用是项目引用，而不是直接指向库输出目录中的 DLL。

另外，除非绝对必要（主 EXE 项目），否则将它们设置为不在本地复制。

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

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

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

我注意到这个问题已经很老了，但这个话题今天仍然很有趣。同样的问题最近困扰了我，最能提高构建性能的两件事是（1）使用专用（且快速）磁盘进行编译，（2）对所有项目使用相同的输出文件夹，并将项目上的 CopyLocal 设置为 False参考。

一些额外的资源：

一些分析工具：

工具 - >选项 - > VC ++项目设置 - >构建时间=是的，会告诉您为每个VCPROJ构建时间。

添加 /Bt 切换到编译器命令行查看每个 CPP 文件占用了多少时间

使用 /showIncludes 捕获嵌套包含（包含其他头文件的头文件），并查看哪些文件可以通过使用前向声明来节省大量 IO。

这将帮助您通过消除依赖性和性能消耗来优化编译器性能。

在花钱购买更快的硬盘之前，请尝试完全在 RAM 磁盘上构建您的项目（假设您有空闲 RAM）。您可以在网上找到各种免费的 RAM 磁盘驱动程序。您不会发现任何物理驱动器（包括 SSD）比 RAM 磁盘更快。

就我而言，使用 Incredibuild 在 7200 RPM SATA 驱动器上的 6 核 i7 上构建需要 5 分钟的项目，通过使用 RAM 磁盘仅缩短了约 15 秒。考虑到需要重新复制到永久存储以及丢失工作的可能性，15 秒不足以激励使用 RAM 磁盘，并且可能没有太多激励去花费数百美元购买高 RPM 或 SSD 驱动器。

微小的增益可能表明构建受 CPU 限制或者 Windows 文件缓存相当有效，但由于这两个测试都是在文件未缓存的状态下完成的，因此我严重倾向于 CPU 限制编译。

根据您正在编译的实际代码，您的里程可能会有所不同 - 所以请不要犹豫进行测试。

完成完整构建后，您的构建目录有多大？如果您坚持使用默认设置，那么您构建的每个程序集都将复制其依赖项的所有 DLL 及其依赖项的依赖项等。到它的 bin 目录。在我之前的工作中，当我处理约 40 个项目的解决方案时，我的同事发现，到目前为止，构建过程中最昂贵的部分是一遍又一遍地复制这些程序集，并且一个构建可能会一遍又一遍地生成相同 DLL 的千兆字节副本。再次。

以下是 NDepend 的作者 Patrick Smacchia 提出的一些有用的建议，关于他认为哪些内容应该是单独的程序集，哪些内容不应该是单独的程序集：

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

基本上有两种方法可以解决这个问题，但这两种方法都有缺点。一是减少装配数量，这显然是一个很大的工作量。另一个方法是重组构建目录，以便整合所有 bin 文件夹，并且项目不会复制其依赖项的 DLL - 它们不需要，因为它们都已经位于同一目录中。这极大地减少了构建期间创建和复制的文件数量，但设置起来可能很困难，并且可能会给您带来一些困难，仅提取特定可执行文件所需的 DLL 进行打包。

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

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

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

并且一定要检查你的预编译头设置。布鲁斯道森的指南有点旧，但仍然非常好 - 检查一下： http://www.cygnus-software.com/papers/precompiledheaders.html

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

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

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

我使用了不同的 IDE (Zeus)，因为我喜欢控制 .rc 文件等内容，并且实际上更喜欢从命令行进行编译，即使我使用的是 MS 编译器。

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

禁用源目录上的文件系统索引（如果您希望源可搜索，则特别是 obj 目录）

如果这是一个 Web 应用程序，则根据具体情况将批量构建设置为 true 会有所帮助。

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

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

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

那是：

项目 A 引用项目 B

项目 B 参考项目 C

项目 C 引用项目 A

Xoreax IB 的一种更便宜的替代方案是使用我所说的 uber-file 构建。它基本上是一个 .cpp 文件，其中包含

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

然后编译超级单元而不是单个模块。我们发现编译时间从 10-15 分钟缩短到 1-2 分钟。您可能需要尝试每个 uber 文件有多少 #include 才有意义。取决于项目。ETC。也许您包含 10 个文件，也许 20 个。

您付出了一定的代价，所以要注意：

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

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

如果它是 C++ 项目，那么您应该使用预编译头。这在编译时间上产生了巨大的差异。不确定 cl.exe 真正在做什么（不使用预编译头），它似乎正在寻找地段在最终到达正确位置之前，所有 STL 标头都位于错误的位置。这会为正在编译的每个 .cpp 文件增加整整几秒的时间。不确定这是 cl.exe 错误，还是 VS2008 中的某种 STL 问题。

查看您正在构建的机器，它的配置是否处于最佳状态？

我们刚刚将最大的 C++ 企业级产品的构建时间从 19小时 到 16分钟 确保安装了正确的 SATA 筛选器驱动程序。

微妙的。

Visual Studio 2005 中有未记录的 /MP 开关，请参阅 http://lahsiv.net/blog/?p=40, ，这将启用基于文件而不是基于项目的并行编译。这可能会加快最后一个项目的编译速度，或者如果您编译一个项目的话。

选择CPU时：L1 缓存大小似乎对编译时间有巨大影响。此外，拥有 2 个快速核心通常比拥有 4 个慢速核心更好。Visual Studio 不能非常有效地使用额外的内核。（这是基于我使用 C++ 编译器的经验，但对于 C# 编译器来说可能也是如此。）

我现在也确信 VS2008 有问题。我在一台配备 3G RAM 的双核 Intel 笔记本电脑上运行它，并关闭了防病毒功能。编译解决方案通常非常顺利，但如果我一直在调试，后续的重新编译通常会变得缓慢。从连续的主磁盘指示灯可以清楚地看出存在磁盘 I/O 瓶颈（您也可以听到）。如果我取消构建并关闭 VS，磁盘活动就会停止。重启VS，重新加载解决方案然后重建，速度快多了。下次再来吧

我的想法是，这是一个内存分页问题 - VS 只是内存不足，操作系统开始页面交换以尝试腾出空间，但 VS 的要求超出了页面交换所能提供的范围，因此它的速度慢得像爬行一样。我想不出任何其他解释。

VS 绝对不是 RAD 工具，是吗？

您的公司是否碰巧使用 Entrust 作为其 PKI/加密解决方案？事实证明，对于一个用 C# 构建的相当大的网站，我们的构建性能非常糟糕，在 Rebuild-All 上花费了 7 分钟多的时间。

我的机器是 i7-3770，配备 16GB 内存和 512GB SSD，所以性能应该不会那么差。我注意到在构建相同代码库的旧辅助机器上我的构建时间要快得多。因此，我在两台机器上启动了 ProcMon，分析了构建并比较了结果。

你瞧，这台运行缓慢的机器有一个区别——堆栈跟踪中对 Entrust.dll 的引用。利用这个新获得的信息，我继续搜索 StackOverflow 并发现了这个： MSBUILD (VS2010) 在某些机器上非常慢. 。根据接受的答案，问题在于 Entrust 处理程序正在处理 .NET 证书检查，而不是本机 Microsoft 处理程序。还建议 Entrust v10 解决 Entrust 9 中普遍存在的这个问题。

我目前已卸载它，我的构建时间骤降到 24秒. 。YYMV 包含您当前正在构建的项目数量，可能无法直接解决您所询问的扩展问题。如果我可以提供修复，我将对此回复进行编辑没有诉诸卸载软件。

肯定是VS2008有问题。因为我所做的唯一一件事就是安装VS2008来升级我用VS2005创建的项目。我的解决方案中只有 2 个项目。它不大。用VS2005编译：VS2008的30秒汇编：5分钟

到目前为止有帮助的好建议（并不是说下面没有其他好建议，如果您遇到问题，我建议您阅读，只是对我们有帮助的内容）

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

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

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

许可以下： CC-BY-SA 和归因

不隶属于 StackOverflow