Visual Studio 2013 中异步解决方案负载性能的改进

[原文发表地址] Asynchronous Solution Load Performance Improvements in Visual Studio 2013 [原文发表时间] 2013-10-14 改善解决方案的负载 过去的几年中,Visual Studio 团队一直在努力提高开发大型解决方案的Visual Studio 的性能和可扩展性。你们很多人特别感兴趣的一个领域是我们最初的解决方案的加载时间。对于Visual Studio 2012,我们实现了使大型解决方案异步加载,这将大大提高我们许多用户的加载速度。对于Visual Studio 2013,我们通过将文档选项卡的初始化推迟到文档被需要使用时,来提高解决方案的负载性能。在这篇文章中,我们将帮助你看到在最新版本中期望看到的变化,以及一些我们从使用预发布版本的客户那里看到的早期性能数据。 大负载 在此之前的VS 2012 ,解决方案是所有资源一次性加载。在加载期间,整个 IDE 将被阻挡,直到为解决方案可用而做的所有必要的准备和初始化完成时为止。使用更大的解决方案的用户可能熟悉此对话框: 对于只有几个项目的一个小的解决方案,加载通常不会花太多时间。但随着解决方案的复杂性和大小的增加,加载该解决方案所需的时间也会增长,等待此对话框消失的时间也会增长。所以当使用VS 2012时,我们问过自己,”如果我们只加载用户需要工作的项目,会发生什么?” 去异步 我们的理由是,在任何时候,开发人员只能积极地工作在一个解决方案中的几个项目。当解决方案被关闭时,如果我们能够确定哪些项目对于开发者来说是最重要的,那么我们就可以在下一次解决方案的加载时,先加载这些项目。其余的项目则可以在不影响开发人员的生产效率的某个时间加载。 上述文章描述了异步加载的解决方案,所以我不会在这里详谈了。但对于这个话题,知道的关键概念是,我们用打开的文档,来确定哪些项目应该在下一次解决方案加载时首先被加载。使用“局部性原理”的概念,我们可以推断,如果一个文件打开着,而该解决方案已经关闭,那么它很可能会在解决方案重新开启后不久被再次需要。为了确保解决方案加载之后该文件是处于可用状态,我们必须载入拥有该文档的项目(以及它所依赖的任何项目),以确保编辑和导航按预期方式工作。因为我们用一个模态对话框阻碍了UI,直到加载完成,我们称此为溶解负载的模态阶段。剩余的项目将在稍后的时间中被异步加载,他们将不会影响开发者的生产效率(被称为意料之中异步阶段)。 进度! 我们的内部测试表明:从异步加载的解决方案中获得重大的潜在收益,但最终的问题是在实践中用户得到了多少收益。为了实现此目的,我们添加了新的遥测点,使我们能够分析异步解决方案加载在我们的客户那里的工作性能如何。使用这些遥测点,我们可以计算出发生Visual Studio 2012 更新3上的负载。虽然也可以异步加载单个项目的解决方案,但他们不是这些改进的重点作用对象,所以我们将首先着眼于至少包含2 个项目的加载。 这些数字是很有前途的。我们查看所有解决方案加载的四分之一,我们推迟加载超过解决方案60%的比例,仅阻碍 IDE 2 秒左右。解决方案加载更多时,我们开始看到异步解决方案负载产生的影响开始减少。到75 个百分点时,解决方案加载几乎同步加载整个解决方案并且响应时间大大增加。 尽管只有 2 个项目的解决方案可以受益于异步加载,但我们预期对于更大的解决方案的影响会更明显。例如,当针对具有 10 个或更多的项目的更大的解决方案时,我们可以看到异步加载产生了更大的影响。 到75 个百分点时,项目的延迟加载比例从 0.3%增加到 18%。虽然模态加载时间略有增加,但如果不推迟项目的加载的话,它将会大得多。 虽然这是令人鼓舞的进展,但是我们想知道什么可以进一步增加异步加载的项目的数目。我们再来看我们的遥测,发现了与速度较慢的加载密切相关的变量之一,即会话之间保持打开状态的文档的数目。 看看在这种方式下只有一个项目并且只有一个打开着的文档的加载,这将会导致模式加载项目的数量大大增加。我们仍然的在IDE的响应时间量上看到明显的改善,但显然有进一步改进的余地。…

1