133

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

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

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

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

更新 我没有提到这是一个 C# 解决方案。感谢所有 C++ 建议，但几年前我不得不担心标题。

编辑：

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

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

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

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

解决方法

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

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

4

34 回答 34

74

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

按加速递减顺序：

  • 安装 Microsoft 修补程序935225。
  • 安装 Microsoft 修补程序947315。
  • 使用真正的多核处理器（即 Intel Core Duo 2；而不是 Pentium 4 HT）。
  • 使用 3 个并行构建。在 Visual Studio 2005 中，您将在Tools > Options... > Projects and Solutions > Build and Run > maximum number of parallel project builds中找到该选项。
  • 禁用 .ilk、.pdb、.cc、.h 文件的防病毒软件，仅在modify上检查病毒。禁用扫描源所在的目录。不要做傻事。
  • 在第二个硬盘驱动器上存储和构建 Chromium 代码。它不会真正加快构建速度，但至少当您执行 gclient 同步或构建时，您的计算机将保持响应。
  • 定期对硬盘进行碎片整理。
  • 禁用虚拟内存。
于 2008-09-11T01:34:44.267 回答
59

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

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

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

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

2015 年 5 月更新

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

于 2011-07-08T15:18:35.290 回答
24

我在一个有 21 个项目和 1/2 百万 LOC 的解决方案上遇到了类似的问题。最大的不同是获得更快的硬盘驱动器。从性能监视器'Avg。Disk Queue'会在笔记本电脑上显着增加，表明硬盘驱动器是瓶颈。

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

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

重建时间 = 112 秒。

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

重建时间 = 72 秒。

3) Desktop Core 2 Duo 3Ghz，单 10000 RPM WD Raptor

重建时间 = 39 秒。

不能低估 10,000 RPM 驱动器。构建速度明显更快，加上显示文档等其他所有内容，使用文件资源管理器明显更快。通过加快代码构建运行周期，极大地提高了生产力。

考虑到公司在开发人员工资上的花费，他们可以浪费多少来为他们配备与接待员使用的 PC 相同的 PC。

于 2008-12-12T01:20:55.810 回答
16

对于 C# .NET 构建，您可以使用.NET Demon。它是一个接管 Visual Studio 构建过程以使其更快的产品。

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

于 2012-05-11T15:58:11.707 回答
14

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

于 2008-09-11T22:48:54.297 回答
12

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

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

于 2008-09-10T23:59:46.553 回答
11

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

不幸的是，Visual Studio 不够聪明，无法将程序集的接口更改与无关紧要的代码主体更改区分开来。这一事实，当与大型交织的解决方案相结合时，有时几乎每次您更改一行代码时都会产生一场不需要的“完整构建”的完美风暴。

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

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

要使此策略起作用，AssemblyInfo 和 GlobalAssemblyInfo 文件中的 VersionNumber 必须在开发人员的机器上保持静态（当然不是在发布构建期间），并且您不签署您的 DLL。

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

于 2011-05-25T21:44:00.340 回答
8

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

于 2008-09-11T00:13:44.787 回答
7

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

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

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

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

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

第二种只有一个项目（构建速度更快）的解决方案将比所有开发人员都完成测试和调试的项目。不过，您必须照顾他们查看构建服务器！如果有任何问题必须修复。

于 2008-11-08T14:24:03.927 回答
7

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

此外，将这些设置为不复制到本地，除非绝对必要（主 EXE 项目）。

于 2008-11-08T14:32:18.700 回答
6

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

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

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

于 2008-09-10T23:59:56.443 回答
6

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

一些额外的资源：

于 2010-05-27T08:35:39.590 回答
5

一些分析工具：

tools->options->VC++ project settings -> Build Timing = Yes 会告诉你每个 vcproj 的构建时间。

将/Bt开关添加到编译器命令行以查看每个 CPP 文件占用了多少

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

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

于 2010-08-24T15:25:51.230 回答
5

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

在我的例子中，一个需要 5 分钟才能在 7200 RPM SATA 驱动器上使用 Incredibuild 构建 6 核 i7 的项目使用 RAM 磁盘仅减少了大约 15 秒。考虑到重新复制到永久存储的需要和丢失工作的可能性，15 秒不足以激励使用 RAM 磁盘，也可能不足以激励在高 RPM 或 SSD 驱动器上花费数百美元。

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

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

于 2010-09-14T22:26:19.997 回答
3

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

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

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

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

于 2011-01-10T15:38:47.470 回答
2

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

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

于 2008-09-11T00:07:39.623 回答
2

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

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

于 2008-09-11T00:56:21.580 回答
2

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

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

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

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

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

于 2008-09-11T01:05:55.023 回答
2

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

于 2008-11-08T14:33:24.623 回答
1

如果这是一个 Web 应用程序，将批处理构建设置为 true 可能会有所帮助，具体取决于场景。

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

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

于 2008-09-11T00:14:04.477 回答
1

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

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

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

你付出了代价，所以要小心：

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

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

于 2008-09-11T01:18:23.823 回答
1

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

那是：

项目 A 参考项目 B

项目 B 参考项目 C

项目 C 引用项目 A

于 2008-09-11T02:26:07.730 回答
1

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

于 2009-10-22T16:04:52.283 回答
1

查看您正在构建的机器，它是否经过优化配置？

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

微妙的。

于 2009-12-01T14:26:41.753 回答
1

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

于 2010-08-24T15:23:01.220 回答
1

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

于 2010-09-16T12:39:37.743 回答
1

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

我的想法是这是一个内存分页问题 - VS 只是内存不足，O/S 开始页面交换以尝试腾出空间，但 VS 要求的比页面交换所能提供的更多，所以它会慢下来。我想不出任何其他解释。

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

于 2010-10-01T14:07:13.187 回答
1

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

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

瞧，性能慢的机器有一个不同之处——堆栈跟踪中对 Entrust.dll 的引用。使用这个新获得的信息，我继续搜索 StackOverflow 并发现：MSBUILD (VS2010) very slow on some machines。根据接受的答案，问题在于 Entrust 处理程序正在处理 .NET 证书检查，而不是本机 Microsoft 处理程序。Tt 还建议 Entrust v10 解决了 Entrust 9 中普遍存在的这个问题。

我目前已将其卸载，并且我的构建时间下降到24 秒。YYMV 与您当前正在构建的项目数量，可能无法直接解决您询问的扩展问题。如果我可以在不诉诸卸载软件的情况下提供修复程序，我将对此回复进行编辑。

于 2013-04-30T15:54:59.767 回答
0

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

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

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

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

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

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

于 2008-09-11T22:35:20.727 回答
0

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

于 2009-03-31T14:29:39.267 回答
0

我发现有一些东西对加速C# /.NET构建很有用：

  • 将小项目组合成更大的项目，因为构建解决方案的每个项目开销很大。（如果需要控制跨层调用，请使用nDepend ）

  • 将我们所有的项目构建到某个输出目录中，然后在所有项目引用上将“copy local”设置为 false - 由于减少 IO，这可能会导致很大的加速。

  • 打开你的病毒检查器，看看它是否有很大的不同；如果是这样，请找到更快的病毒检查程序，或从病毒检查程序扫描中排除“热”文件夹

  • 使用 perforce 监视器和 sys 内部工具来查看您的编译需要这么长时间。

  • 考虑一个 ram 磁盘来放置你的输出目录。

  • 考虑使用 SSD

  • 更多的内存有时会产生很大的影响——（如果你通过移除一个小内存而大大减慢了机器中的内存，你可以通过添加更多内存来获得很大的速度）删除不需要的项目引用（你可能必须首先删除不需要的“使用”）

  • 考虑为您的最低域层使用依赖注入框架和接口，因此仅在接口更改时才需要重新编译所有内容 - 根据接口更改的频率，这可能不会获得太大收益。

于 2011-03-25T12:32:28.007 回答
0

我发现以下有助于编译速度： 经过反复编译（内存中的迭代开发），我会退出 VS2008。然后进入项目目录并删除所有obj和bin文件夹，重新启动项目，我的编译时间又回来了。这类似于Clean solutionVS2008 中的操作。

只是想确认这是否对那里的任何人有用。

于 2011-08-03T22:50:59.653 回答
0

我在这里找到了解决方法：http: //blogs.msdn.com/b/vsdteam/archive/2006/09/15/756400.aspx

于 2011-08-30T15:27:49.180 回答
-1

缓慢的 Visual Studio 性能……已解决！2014 年 9 月 24 日，作者：乌兹玛·阿比迪

我今天遇到了一个奇怪的与性能相关的问题。即使是最简单的操作，我的 Microsoft Visual Studio 似乎也需要很长时间才能执行。我四处搜索并尝试了一些人们的想法，例如禁用加载项或清除 Visual Studio 的最近项目列表，但这些建议似乎并没有解决问题。我记得 Windows SysInternals 网站有一个名为 Process Monitor 的工具，它可以嗅探任何正在运行的程序对注册表和文件的访问。在我看来，Visual Studio 是在做某事，而 Process Monitor 应该可以帮助我弄清楚它是什么。我下载了最新版本，在调整了一下显示过滤器后，运行它，令我惊恐的是，我发现 Visual Studio 太慢了，因为它要访问 C 语言中的 10,000 多个文件夹：\Users\krintoul\AppData\Local\Microsoft\WebSiteCache 在大多数 IDE 操作中。我不知道为什么会有这么多文件夹，而且也不知道 Visual Studio 对它们做了什么，但是在我压缩这些文件夹并将它们移动到其他地方之后，Visual Studio 的性能得到了极大的提升。

Windows SysInternals 网站有许多其他有用的实用程序，用于网络管理、安全、系统信息等。看看这个。我相信你会发现一些有价值的东西。

于 2014-09-24T07:34:26.823 回答