• 对于xUnit，您将需要xunit.runner.visualstudio 2.2.0-beta3-build 1187和xunit 2.0版本（或更高版本）
• 对于NUnit，您需要NUnit3TestAdapter 3.5.1版本和NUnit版本3.5.0（或更高版本）
• 对于MSTest，您将需要MSTest.TestAdapter 1.1.4-预览版和MSTest.TestFramework 1.0.5预览版（或更高版本）

如果一行可执行代码只被通过的测试覆盖，实时单元测试将用绿色“✓”来标识它。

如果一行可执行代码没有被任何测试覆盖，实时单元测试将用蓝线来标识它。

[原文发表时间]: October 12, 2016

这是Visual Studio “15” Preview 5中关于性能改善五部分系列中的第三篇博客。前两篇博客介绍的是在Visual Studio “15”中启动更快和项目解决方案加载时间更短。

Visual Studio集多种功能于一身，数百万的开发人员都依赖于它进行高效的工作。支持如此多的功能，而且随着开发者期望的响应速度的提高，内存消耗就有所增加。然而，在Visual Studio 2015中，在某些情况下的内存使用量过大。这导致了一些不利的影响，例如内存溢出崩溃，UI反应迟缓。我们收到了大量用户对于这些问题的反馈。在VS “15”中我们正在解决这些问题，同时不会削弱Visual Studio丰富的功能和性能。

我们正在优化Visual Studio的很多功能，这篇文章介绍了三个具体领域的进展： JavaScript与 TypeScript语言服务，调试器符号文件加载，VS中的Git支持。在本文中我将对每一个测试场景比较以下两个指标，来展示我们所取得的进展：

峰值虚拟内存: Visual Studio是一个32位的应用，这意味着消耗的虚拟内存可以达到4GB。超过上限的内存分配会导致Visual Studio出现内存溢出错误(OOM)而崩溃。峰值虚拟内存是一个用来度量进程的内存将如何接近所限制的4GB的指标，或者换句话说，可以度量一个进程是如何接近崩溃的指标。

峰值私有工作集：一个包含了进程执行的代码或进程涉及的数据的虚拟内存的子集需要被放在物理内存中。“工作集”是这样的物理内存消耗的度量标准。这种工作集的一部分称作“私有工作集”，是属于一个给定进程的内存，并且是单独属于这个进程的。因为这样的内存不是进程间共享的，他们在系统上的消耗相对较高。本文的测量数据包括了Visual Studio (devenv.exe)的峰值私有工作集和相关的附属进程。

JavaScript语言服务

超过三分之一的Visual Studio开发人员定期编写JavaScript (JS)，使JS语言服务成为在相当数量的Visual Studio会话中需要加载的一部分。JS语言服务提供的功能如智能感知、代码导航和一些使JS编辑高效的功能。

为了支持这种生产力特性并且确保他们响应迅速，语言服务消耗了不少的内存。内存的使用量取决于解决方案的特性、工程的数量、文件的数量以及文件大小。此外，JS语言服务通常会和另一种语言服务一起被加载，例如C#，这会增加进程的内存压力。因此，提高JS语言服务的内存占用对减少VS中内存溢出崩溃是至关重要的。

在VS “15”中，我们想要确保Visual Studio可靠性不会被JS代码造成的内存消耗而不利地影响。为了实现这个目标而不影响JavaScript的编辑体验，在VS“15” Preview 5中我们已经将整个JS语言服务移动到一个可以与Visual Studio进行通信的附属进程Node,js中。我们还合并了JavaScript和TypeScript语言服务，这意味着我们通过实现两种语言服务被同时加载来减少内存。

为了测量对内存的影响，我们在以下场景中比较了Visual Studio 2015 Update 3 和VS “15” Preview 5中的峰值虚拟内存和峰值私有工作集：

• 打开WebSpaDurandal解决方案。这是一个Asp.Net的例子
• 创建并启用_references.js的自动同步
• 打开10个JS文件
• 进行编辑，启动完成，创建/删除文件，运行格式工具

这是比较结果：

表1：JavaScript语言服务的内存使用量

Visual Studio的峰值虚拟内存使用减少了33%，这为今天面临内存溢出崩溃的JS开发人员提供了较大的帮助。总体的峰值私有工作集代表Preview 5中Visual Studio进程和我们的附属进程的总和，与Visual Studio 2015中的差不多。

调试器符号文件加载

符号信息对有效的调试来说是至关重要的。Windows里大多数的微软编辑器将符号信息存储在一个PDB文件里面。一个PDB文件包含大量代码信息，例如，函数名称，可执行的二进制文件的偏移量，类的类型信息和可执行文件中定义的结构，资源文件名称等等。当Visual Studio调试器显示一个调用堆栈，计算一个变量或表达式等等时，它加载相应的PDB文件并读取相关信息。

在Visual Studio 2012之前，用复杂的natvis视图评估类型的性能不够理想。这是因为大量的类型信息会根据需要从PDB获取，这将导致对磁盘上的PDB文件随机的输入输出。在多数驱动器上这都将表现不佳。

在Visual Studio 2012 中，C++调试器中增加了一个新特性：会在早期的调试环节从PDB文件中提前提取大量的符号数据。这就显著地改进了性能。

不幸的是，在提前提取符号数据时，这种优化错误很多。在某些情况下，它导致了比需要的更多的符号数据被读取。例如，显示调用堆栈时，栈上的所有模块的符号数据都将被提取到，即使是那些在Locals 或者Watch 窗口里不需要被评估类型的数据。在大型的项目中有很多可用的符号数据模型，这将导致在每一个调试会话中使用大量的内存。

在VS “15” Preview 5中，我们已经采取措施来减少符号信息的内存使用，同时保持预先提取的性能优势。我们现在只有在模块被要求评估和显示一个变量或者表达式时启用预提取。

我们通过以下场景来测试对内存的影响：

• 加载Unreal Engine解决方案，UE4.sln
• 启动Unreal Engine Editor
• 将VS调试器附加到Unreal Engine进程
• 在E:\UEngine\Engine\Source\Runtime\Core\Public\Delegates\DelegateInstancesImpl_Variadics.inl的640行设置断点
• 直到停在断点

这是结果：

表2：当VS调试器被附加到Unreal Engine进程时的内存使用情况

在此场景中由于内存溢出导致VS 2015崩溃。VS “15” Preview 5消耗虚拟内存3GB和私有工作集1.8GB。相比以前版本，这显然得到了改善，但也还不是期望的值。我们将继续在以后的VS “15”开发中减少本地调试方案的内存使用。

Visual Studio的Git支持

当我们在Visual Studio中引入Git支持时，我们使用了一个名为libgit2的库。对于各种操作，libgit2会映射整个git索引文件到内存中。索引文件的大小与代码库大小成正比。这意味着对于大的代码库，Git操作会导致大量的虚拟内存消耗。如果VS已经遭遇虚拟内存压力，这些消耗会导致内存溢出崩溃。

在VS “15” Preview 5，我们不再使用libgit2而是调用git.exe，因此避免了VS进程的虚拟内存消耗。我们使用git.exe不仅为了减少了VS进程的内存使用量，而且它也使我们增加和构建功能更加容易。

为了测量一个Git操作对于内存增量的影响，我们在下面的场景中比较了Visual Studio 2015 Update 3和VS “15” Preview 5：

• 打开Team Explore的 Chromium repo
• 到“Changes”面板查看待定的更改
• 点击F5进行刷新

这是结果：

表3：当Team Explore的“Changes”面板被刷新时内存使用量的增长情况

VS 2015中，在更新操作期间虚拟内存消耗大约300MB。在VS “15”中，没有显著的虚拟内存的增加。VS 2015的私有工作集的增量是79MB，而VS “15”是72MB，完全是来自git.exe.

总结

在 VS “15”中，我们正在努力减少Visual Studio的内存使用量。在这篇文章中，我介绍了我们在三个功能上所取得的进展。但是，在取得成功的道路上我们仍然有很多的工作要做。

您可以通过以下途径来帮助我们：

第一种，我们会观察所有发布版本的遥测，包括预发布版本。所以请下载并使用VS “15” Preview 5。我们能在您的日常使用中获取到的外部资源越多，得到的信息就越准确，这将会极大地帮助到我们。

第二种，使用Report-a-problem工具来报告高内存（或者其他质量）问题。报告里最好能够通过提供给我们一个例子或者一个真实的方案来最终重现问题。我知道也不是只能这么做，如果能在报告问题时附加一段问题重现记录（我们的Report-a-problem工具可以帮你很容易做到）并且尽可能描述更多的信息就更好了。]]> https://docs.microsoft.com/archive/blogs/visualstudio_cn/visual-studio15%E7%9A%84%E5%86%85%E5%AD%98%E6%BA%A2%E5%87%BA%E5%B4%A9%E6%BA%83%E9%94%90%E5%87%8F Fri, 24 Mar 2017 05:24:40 GMT https://blogs.msdn.microsoft.com/visualstudio_cn/?p=2276 [原文发表地址]: Reduced Out of Memory Crashes in Visual Studio “15”

[原文发表时间]: October 12, 2016

这是Visual Studio “15” Preview 5中关于性能改善五部分系列中的第三篇博客。前两篇博客介绍的是在Visual Studio “15”中启动更快和项目解决方案加载时间更短。

Visual Studio集多种功能于一身，数百万的开发人员都依赖于它进行高效的工作。支持如此多的功能，而且随着开发者期望的响应速度的提高，内存消耗就有所增加。然而，在Visual Studio 2015中，在某些情况下的内存使用量过大。这导致了一些不利的影响，例如内存溢出崩溃，UI反应迟缓。我们收到了大量用户对于这些问题的反馈。在VS “15”中我们正在解决这些问题，同时不会削弱Visual Studio丰富的功能和性能。

我们正在优化Visual Studio的很多功能，这篇文章介绍了三个具体领域的进展： JavaScript与 TypeScript语言服务，调试器符号文件加载，VS中的Git支持。在本文中我将对每一个测试场景比较以下两个指标，来展示我们所取得的进展：

峰值虚拟内存: Visual Studio是一个32位的应用，这意味着消耗的虚拟内存可以达到4GB。超过上限的内存分配会导致Visual Studio出现内存溢出错误(OOM)而崩溃。峰值虚拟内存是一个用来度量进程的内存将如何接近所限制的4GB的指标，或者换句话说，可以度量一个进程是如何接近崩溃的指标。

峰值私有工作集：一个包含了进程执行的代码或进程涉及的数据的虚拟内存的子集需要被放在物理内存中。“工作集”是这样的物理内存消耗的度量标准。这种工作集的一部分称作“私有工作集”，是属于一个给定进程的内存，并且是单独属于这个进程的。因为这样的内存不是进程间共享的，他们在系统上的消耗相对较高。本文的测量数据包括了Visual Studio (devenv.exe)的峰值私有工作集和相关的附属进程。

JavaScript语言服务

超过三分之一的Visual Studio开发人员定期编写JavaScript (JS)，使JS语言服务成为在相当数量的Visual Studio会话中需要加载的一部分。JS语言服务提供的功能如智能感知、代码导航和一些使JS编辑高效的功能。

为了支持这种生产力特性并且确保他们响应迅速，语言服务消耗了不少的内存。内存的使用量取决于解决方案的特性、工程的数量、文件的数量以及文件大小。此外，JS语言服务通常会和另一种语言服务一起被加载，例如C#，这会增加进程的内存压力。因此，提高JS语言服务的内存占用对减少VS中内存溢出崩溃是至关重要的。

在VS “15”中，我们想要确保Visual Studio可靠性不会被JS代码造成的内存消耗而不利地影响。为了实现这个目标而不影响JavaScript的编辑体验，在VS“15” Preview 5中我们已经将整个JS语言服务移动到一个可以与Visual Studio进行通信的附属进程Node,js中。我们还合并了JavaScript和TypeScript语言服务，这意味着我们通过实现两种语言服务被同时加载来减少内存。

为了测量对内存的影响，我们在以下场景中比较了Visual Studio 2015 Update 3 和VS “15” Preview 5中的峰值虚拟内存和峰值私有工作集：

• 打开WebSpaDurandal解决方案。这是一个Asp.Net的例子
• 创建并启用_references.js的自动同步
• 打开10个JS文件
• 进行编辑，启动完成，创建/删除文件，运行格式工具

这是比较结果：

表1：JavaScript语言服务的内存使用量

Visual Studio的峰值虚拟内存使用减少了33%，这为今天面临内存溢出崩溃的JS开发人员提供了较大的帮助。总体的峰值私有工作集代表Preview 5中Visual Studio进程和我们的附属进程的总和，与Visual Studio 2015中的差不多。

调试器符号文件加载

符号信息对有效的调试来说是至关重要的。Windows里大多数的微软编辑器将符号信息存储在一个PDB文件里面。一个PDB文件包含大量代码信息，例如，函数名称，可执行的二进制文件的偏移量，类的类型信息和可执行文件中定义的结构，资源文件名称等等。当Visual Studio调试器显示一个调用堆栈，计算一个变量或表达式等等时，它加载相应的PDB文件并读取相关信息。

在Visual Studio 2012之前，用复杂的natvis视图评估类型的性能不够理想。这是因为大量的类型信息会根据需要从PDB获取，这将导致对磁盘上的PDB文件随机的输入输出。在多数驱动器上这都将表现不佳。

在Visual Studio 2012 中，C++调试器中增加了一个新特性：会在早期的调试环节从PDB文件中提前提取大量的符号数据。这就显著地改进了性能。

不幸的是，在提前提取符号数据时，这种优化错误很多。在某些情况下，它导致了比需要的更多的符号数据被读取。例如，显示调用堆栈时，栈上的所有模块的符号数据都将被提取到，即使是那些在Locals 或者Watch 窗口里不需要被评估类型的数据。在大型的项目中有很多可用的符号数据模型，这将导致在每一个调试会话中使用大量的内存。

在VS “15” Preview 5中，我们已经采取措施来减少符号信息的内存使用，同时保持预先提取的性能优势。我们现在只有在模块被要求评估和显示一个变量或者表达式时启用预提取。

我们通过以下场景来测试对内存的影响：

• 加载Unreal Engine解决方案，UE4.sln
• 启动Unreal Engine Editor
• 将VS调试器附加到Unreal Engine进程
• 在E:\UEngine\Engine\Source\Runtime\Core\Public\Delegates\DelegateInstancesImpl_Variadics.inl的640行设置断点
• 直到停在断点

这是结果：

表2：当VS调试器被附加到Unreal Engine进程时的内存使用情况

在此场景中由于内存溢出导致VS 2015崩溃。VS “15” Preview 5消耗虚拟内存3GB和私有工作集1.8GB。相比以前版本，这显然得到了改善，但也还不是期望的值。我们将继续在以后的VS “15”开发中减少本地调试方案的内存使用。

Visual Studio的Git支持

当我们在Visual Studio中引入Git支持时，我们使用了一个名为libgit2的库。对于各种操作，libgit2会映射整个git索引文件到内存中。索引文件的大小与代码库大小成正比。这意味着对于大的代码库，Git操作会导致大量的虚拟内存消耗。如果VS已经遭遇虚拟内存压力，这些消耗会导致内存溢出崩溃。

在VS “15” Preview 5，我们不再使用libgit2而是调用git.exe，因此避免了VS进程的虚拟内存消耗。我们使用git.exe不仅为了减少了VS进程的内存使用量，而且它也使我们增加和构建功能更加容易。

为了测量一个Git操作对于内存增量的影响，我们在下面的场景中比较了Visual Studio 2015 Update 3和VS “15” Preview 5：

• 打开Team Explore的 Chromium repo
• 到“Changes”面板查看待定的更改
• 点击F5进行刷新

这是结果：

表3：当Team Explore的“Changes”面板被刷新时内存使用量的增长情况

VS 2015中，在更新操作期间虚拟内存消耗大约300MB。在VS “15”中，没有显著的虚拟内存的增加。VS 2015的私有工作集的增量是79MB，而VS “15”是72MB，完全是来自git.exe.

总结

在 VS “15”中，我们正在努力减少Visual Studio的内存使用量。在这篇文章中，我介绍了我们在三个功能上所取得的进展。但是，在取得成功的道路上我们仍然有很多的工作要做。

您可以通过以下途径来帮助我们：

第一种，我们会观察所有发布版本的遥测，包括预发布版本。所以请下载并使用VS “15” Preview 5。我们能在您的日常使用中获取到的外部资源越多，得到的信息就越准确，这将会极大地帮助到我们。

第二种，使用Report-a-problem工具来报告高内存（或者其他质量）问题。报告里最好能够通过提供给我们一个例子或者一个真实的方案来最终重现问题。我知道也不是只能这么做，如果能在报告问题时附加一段问题重现记录（我们的Report-a-problem工具可以帮你很容易做到）并且尽可能描述更多的信息就更好了。]]> https://docs.microsoft.com/archive/blogs/visualstudio_cn/visual-studio-15%E5%93%8D%E5%BA%94%E9%80%9F%E5%BA%A6%E6%9B%B4%E5%BF%AB-2 Thu, 23 Mar 2017 01:56:01 GMT https://blogs.msdn.microsoft.com/visualstudio_cn/?p=2235 [原文发表地址]: Improved overall Visual Studio “15” Responsiveness

[原文发表时间]: October 14, 2016

这是包含Visual Studio “15” 性能提升5部分系列的最后一篇博客了。

这个系列中包含了下边的内容：

· Visual Studio "15" 启动更快了

· VS“15”项目解决方案加载时间更短

· VS“15”中由于内存溢出产生的崩溃现象减少了

· VS“15”让C++工程更快

· VS “15” 响应速度更快

在这篇博客中我们会着重介绍下在VS “15” 预览版5中我们所做的一些让Visual Studio在日常使用过程中 反应更加灵敏的改进。首先，我们先讲一下在调试性能、Git源代码管理和XAML编辑方面的改进，以及怎样通过管理插件来改进你的输入体验。

调试更快速并且不会因为编辑造成延迟

在Visual studio 2005中，我们引进了WPF工程、windows窗体工程和可管理控制台项目的托管进程，通过在后台启动一个可用于下一个调试会话的进程，来使“开始调试”速度更快。该功能会导致Visual Studio在按下“停止调试”时暂时性的几秒钟内无响应或者是只能在停止调试会话之后才能使用Visual Studio。

在预览版5当中，我们关闭了托管进程，并且优化了“开始调试”，这就使得如没有托管过程一样快速，而对于从未使用过托管过程的项目（例如ASP.NET，Universal Windows和C ++）来说可能会更快。例如，下边是一些我们在测试机器上所统计的UWP照片共享应用程序、一个针对于可视化的C++应用程序和一个简单的WPF应用程序的启动时间对比图：

为了实现以上提升，我们在开始调试路径上优化了初始化诊断工具窗口和智能追踪（默认情况下会在每一个调试会话开始的时候显示）的相关时间花费。我们修改了智能追踪的初始化模式，这样的话它就可以在其他调试过程和应用启动的时候被初始化。另外，我们通过智能追踪记录和Visual Studio进程在断点处停止时的交互的方式消除了几个低效率进程。

我们还删除了几个与诊断工具窗口相关的必须在Visual Studio UI主线程上同步运行代码的后台线程。 这使得我们可以异步进行ETW事件收集，从而在重新启动调试时，不必等待旧的ETW会话完成。

Git.exe 的源代码操作更快

当我们在Visual Studio中引入Git支持时，我们使用了一个名为libgit2的库。 使用libgit2时，我们会遇到和从命令提示符使用git.exe的功能时的一个不同的问题，libgit2会为主Visual Studio进程添加100 MB的内存压力。

在VS15预览版本5中，我们已经用在进程外调用git.exe去替换那种实现方式， 所以尽管git还是使用机器的内存，但是不会增加内存压力给主VS进程。我们也期望随着时间的推移使用Git.exe也允许我们使得git操作更快。到目前为止，我们发现用git 克隆较大的代码库时操作更快， 比如用Visual Studio “15”克隆Roslyn.NET 编译器到我们的机器上比用Visual Studio 2015速度快了30%: 在Visual Studio “15”上需要4分钟，而在Visual Studio 2015 上需要5分40秒。以下视频展示了此信息（为了方便起见，视频是以4倍的速度播放的）：

在接下来的版本中，我们希望通过这个新的框架可以使更多操作更快速。

我们还改进了在使用git时的一个最大问题：用命令行切换分支导致Visual Studio去一个个的重新加载解决方案中的所有项目。在文件更改提示对话框中，我们将“重新加载所有”替换为“重新加载解决方案”：

这将启动单个异步解决方案重新加载，这比单个项目加载快的多。

提高XAML Tab的切换速度

基于统计数据和客户的反馈，我们发现在XAML标签切换时，每天有25% 的开发人员至少会遇到一次标签切换延迟大于1秒的情况。 再进一步调查中，我们发现这些延迟是由运行标记编译器引起的，我们已经用XAML语言服务去使得这个变得更快。以下视频显示了我们所做的改进：

标记编译器为每一个XAML 文件创建g.i.* 文件，其中包含代表XAML文件命名的元素字段，使您能够从代码中引用那些命名元素。例如，给定<Button x:Name=”myButton” />, g.i.* 文件包含一个名字为Button类型的按钮，会允许你在代码中使用“myButton”。

某些用户的操作，比如保存或者切换未保存的XAML文件将导致Visual Studio更新g.i.* 文件以确保当打开隐藏代码文件时IntelliSense有命名元素的最新视图。在已经发布的版本中，g.i.* 文件的更新是由标记编辑器来完成。在托管（C#/VB）项目中，标记编辑器在UI线程上运行，这就导致在复杂项目中的选项卡之间的切换延迟比较明显。

我们在预览版本5中解决了这个问题，通过利用XAMl文件的语言服务知识去确定填充IntelliSens的名称和字段类型， 然后在后台进程中用Roslyn更新g.i.* 文件。这大大快于运行标记编译器，因为语言服务已经完成了那些会导致编译器运行缓慢的解析和类型元数据加载。如果g.i.* 文件不存在（例如：在重命名XAML文件后，或者在删除项目的obj目录之后），我们需要去运行标记编辑器来重新生成g.i.* 文件，您可能仍会看到延迟。

敏捷的XAML输入体验

XAML语言服务中UI延迟的主要原因和初始化、响应元素数据更改和加载设计程序集有关。我们通过把工作转移到后台线程来处理这三个延迟问题。

我们还对加载元数据的设计进行了以下改进：

• 设计元数据时的新的序列化层，极大的减少了跨边界调用。
• 为WPF项目重用设计器程序集的缓存。 对所有项目类型重用缓存。缓存是在每次数据更新时被重新创建的。
• 设计程序集元数据在会话期间存储而不是在每一次元数据更新时就重新计算。

这些更新还允许XAML IntelliSense 在解决方案完全加载之前就可用了。

找出哪些扩展程序导致输入延迟

我们收到了许多关于输入时延迟的反馈。 我们正在继续修正，以改善这些问题。但在许多情况下，输入时的延迟是由于在输入时有扩展程序在运行代码引起的。为了帮您确定是否有扩展会影响您的输入体验，我们已在帮助 - >管理Visual Studio性能里添加了报告，并会在我们检测到扩展程序延迟输入时通知您。

扩展程序延迟输入的通知

你可以在帮助 - >管理Visual Studio性能中看到更多关于扩展的详细信息。

开始尝试并且报告问题吧

我们正在继续改进Visual Studio的响应能力，这篇文章包含了我们在预览版5中完成的一些功能。我们需要您的帮助，来将我们的努力集中在对您最重要的领域，所以请下载Visual Studio '15'Preview 5，并使用Report-a-Problem工具去报告可以使Visual Studio变得更好的任何问题吧。]]> https://docs.microsoft.com/archive/blogs/visualstudio_cn/visual-studio-15%E5%93%8D%E5%BA%94%E9%80%9F%E5%BA%A6%E6%9B%B4%E5%BF%AB Wed, 22 Mar 2017 10:11:17 GMT https://blogs.msdn.microsoft.com/visualstudio_cn/?p=2205 [原文发表地址]: Improved overall Visual Studio “15” Responsiveness

[原文发表时间]: October 14, 2016

这是包含Visual Studio “15” 性能提升5部分系列的最后一篇博客了。

这个系列中包含了下边的内容：

· Visual Studio "15" 启动更快了

· VS“15”项目解决方案加载时间更短

· VS“15”中由于内存溢出产生的崩溃现象减少了

· VS“15”让C++工程更快

· VS “15” 响应速度更快

在这篇博客中我们会着重介绍下在VS “15” 预览版5中我们所做的一些让Visual Studio在日常使用过程中 反应更加灵敏的改进。首先，我们先讲一下在调试性能、Git源代码管理和XAML编辑方面的改进，以及怎样通过管理插件来改进你的输入体验。

调试更快速并且不会因为编辑造成延迟

在Visual studio 2005中，我们引进了WPF工程、windows窗体工程和可管理控制台项目的托管进程，通过在后台启动一个可用于下一个调试会话的进程，来使“开始调试”速度更快。该功能会导致Visual Studio在按下“停止调试”时暂时性的几秒钟内无响应或者是只能在停止调试会话之后才能使用Visual Studio。

在预览版5当中，我们关闭了托管进程，并且优化了“开始调试”，这就使得如没有托管过程一样快速，而对于从未使用过托管过程的项目（例如ASP.NET，Universal Windows和C ++）来说可能会更快。例如，下边是一些我们在测试机器上所统计的UWP照片共享应用程序、一个针对于可视化的C++应用程序和一个简单的WPF应用程序的启动时间对比图：

为了实现以上提升，我们在开始调试路径上优化了初始化诊断工具窗口和智能追踪（默认情况下会在每一个调试会话开始的时候显示）的相关时间花费。我们修改了智能追踪的初始化模式，这样的话它就可以在其他调试过程和应用启动的时候被初始化。另外，我们通过智能追踪记录和Visual Studio进程在断点处停止时的交互的方式消除了几个低效率进程。

我们还删除了几个与诊断工具窗口相关的必须在Visual Studio UI主线程上同步运行代码的后台线程。 这使得我们可以异步进行ETW事件收集，从而在重新启动调试时，不必等待旧的ETW会话完成。

Git.exe 的源代码操作更快

当我们在Visual Studio中引入Git支持时，我们使用了一个名为libgit2的库。 使用libgit2时，我们会遇到和从命令提示符使用git.exe的功能时的一个不同的问题，libgit2会为主Visual Studio进程添加100 MB的内存压力。

在VS15预览版本5中，我们已经用在进程外调用git.exe去替换那种实现方式， 所以尽管git还是使用机器的内存，但是不会增加内存压力给主VS进程。我们也期望随着时间的推移使用Git.exe也允许我们使得git操作更快。到目前为止，我们发现用git 克隆较大的代码库时操作更快， 比如用Visual Studio “15”克隆Roslyn.NET 编译器到我们的机器上比用Visual Studio 2015速度快了30%: 在Visual Studio “15”上需要4分钟，而在Visual Studio 2015 上需要5分40秒。以下视频展示了此信息（为了方便起见，视频是以4倍的速度播放的）：

在接下来的版本中，我们希望通过这个新的框架可以使更多操作更快速。

我们还改进了在使用git时的一个最大问题：用命令行切换分支导致Visual Studio去一个个的重新加载解决方案中的所有项目。在文件更改提示对话框中，我们将“重新加载所有”替换为“重新加载解决方案”：

这将启动单个异步解决方案重新加载，这比单个项目加载快的多。

提高XAML Tab的切换速度

基于统计数据和客户的反馈，我们发现在XAML标签切换时，每天有25% 的开发人员至少会遇到一次标签切换延迟大于1秒的情况。 再进一步调查中，我们发现这些延迟是由运行标记编译器引起的，我们已经用XAML语言服务去使得这个变得更快。以下视频显示了我们所做的改进：

标记编译器为每一个XAML 文件创建g.i.* 文件，其中包含代表XAML文件命名的元素字段，使您能够从代码中引用那些命名元素。例如，给定<Button x:Name=”myButton” />, g.i.* 文件包含一个名字为Button类型的按钮，会允许你在代码中使用“myButton”。

某些用户的操作，比如保存或者切换未保存的XAML文件将导致Visual Studio更新g.i.* 文件以确保当打开隐藏代码文件时IntelliSense有命名元素的最新视图。在已经发布的版本中，g.i.* 文件的更新是由标记编辑器来完成。在托管（C#/VB）项目中，标记编辑器在UI线程上运行，这就导致在复杂项目中的选项卡之间的切换延迟比较明显。

我们在预览版本5中解决了这个问题，通过利用XAMl文件的语言服务知识去确定填充IntelliSens的名称和字段类型， 然后在后台进程中用Roslyn更新g.i.* 文件。这大大快于运行标记编译器，因为语言服务已经完成了那些会导致编译器运行缓慢的解析和类型元数据加载。如果g.i.* 文件不存在（例如：在重命名XAML文件后，或者在删除项目的obj目录之后），我们需要去运行标记编辑器来重新生成g.i.* 文件，您可能仍会看到延迟。

敏捷的XAML输入体验

XAML语言服务中UI延迟的主要原因和初始化、响应元素数据更改和加载设计程序集有关。我们通过把工作转移到后台线程来处理这三个延迟问题。

我们还对加载元数据的设计进行了以下改进：

• 设计元数据时的新的序列化层，极大的减少了跨边界调用。
• 为WPF项目重用设计器程序集的缓存。 对所有项目类型重用缓存。缓存是在每次数据更新时被重新创建的。
• 设计程序集元数据在会话期间存储而不是在每一次元数据更新时就重新计算。

这些更新还允许XAML IntelliSense 在解决方案完全加载之前就可用了。

找出哪些扩展程序导致输入延迟

我们收到了许多关于输入时延迟的反馈。 我们正在继续修正，以改善这些问题。但在许多情况下，输入时的延迟是由于在输入时有扩展程序在运行代码引起的。为了帮您确定是否有扩展会影响您的输入体验，我们已在帮助 - >管理Visual Studio性能里添加了报告，并会在我们检测到扩展程序延迟输入时通知您。

扩展程序延迟输入的通知

你可以在帮助 - >管理Visual Studio性能中看到更多关于扩展的详细信息。

开始尝试并且报告问题吧

我们正在继续改进Visual Studio的响应能力，这篇文章包含了我们在预览版5中完成的一些功能。我们需要您的帮助，来将我们的努力集中在对您最重要的领域，所以请下载Visual Studio '15'Preview 5，并使用Report-a-Problem工具去报告可以使Visual Studio变得更好的任何问题吧。]]> https://docs.microsoft.com/archive/blogs/visualstudio_cn/visual-studio-15-preview-5-%E5%8F%91%E5%B8%83%E5%85%AC%E5%91%8A Fri, 03 Mar 2017 10:23:58 GMT https://blogs.msdn.microsoft.com/visualstudio_cn/?p=2136 [原文发表地址]: Announcing Visual Studio “15” Preview 5

[原文发表时间]: October 5, 2016

今天我们发布了Visual Studio “15” Preview 5版本。对于Preview 5版本, 我想主要介绍下性能方面的改进，在接下来的几天，我们还会有后续的博客来描述我们已经可以看到的性能提升。我打算主要说明下那些已经可以提高效率的改进点。

启动安装程序，并阅读下文，你也可以获取发布说明来了解详情。

性能与内存效率的大改进

我想根据这个并行对比视频，给你展示所有的性能改进。这个视频是比较打开 Visual Studio 并加载整个.NET 编译器平台"Roslyn"的解决方案，Visual Studio '15' 用时30秒，而Visual Studio 2015用时60秒。

更快的加载时间是“轻量级工程加载以及按需求扩展加载”双管齐下改进的结果。下面是一些在Preview 5中的关键性能的提升：

• 通过“轻量级解决方案加载”选项来缩短解决方案加载时间: 工作在超过100多个项目的解决方案中，并不意味着需要在一定时间内操作所有的文件或项目。VS “15”提供了在不需要等待所有工程加载完毕时就可编辑和调试的功能。你可以在Preview5的托管工程中尝试一下这种功能，可以通过工具-> 选项 ->项目和解决方案，勾选“轻量级解决方案加载”。
• 通过按需加载扩展来更快的启动：方法很简单：当需要扩展时再加载，而不是在打开VS的时候就加载。在 Preview 5中，我们开始这样做了，已经改变了Python和Xamarin扩展为按需加载，并正在改变我们提供的所有Visual Studio扩展，以及由第三方扩展供应商所提供的扩展到这种模式。想知道哪些扩展影响了启动，解决方案加载等性能呢？你可以在帮助->管理Visual Studio性能中查看这些信息。你开发过扩展吗？我们将发布指导来帮助扩展开发人员将扩展改为按需加载。
• 将子系统从VS主进程移动到独立进程: 我们移动了一些内存密集型任务，例如 Git 源代码管理、JavaScript 和TypeScript语言服务，以便分离进程。这就杜绝了那些较差的体验，如由于代码运行Visual Studio的程序造成的延时，或者因32位的处理器中主程序已有达到约4 GB的内存上限造成的Visual Studio变得缓慢或者崩溃。在未来的版本中，我们将继续把组件移动到进程外。
• 对C++项目，更快的加载项目，编码，调试: 我们可以更快的加载C++项目，查看这个显示改进的视频。你可以通过从工具->选项->文本编辑->C/C++->实验，将“启用更快的项目加载”的值设置为True来启用它。我们也改进了我们的链接器和PDB加载库，使得增量生成工程以及调试时更快，同时在调试的时候所消耗的内存也明显减少了。
• 使用Git、调试工程和编辑XAML代码时速度有所提升：通过从libgit2切换到git.exe，我们提高了源代码管理操作的速度。我们也通过优化初始化时间和其他与IntelliTrace相关的时间，以及诊断工具窗口，还删除了编辑XAML文件时出现的几次延迟。从而提高了调试性能。

这只是开始，我们会专注于做这种改进，让Visual Studio启动的更快，更敏捷的反应时间，以及占用更少的内存。在未来几天，请留心注意Visual Studio博客的帖子，我们会深入讨论这些改进技术的细节。

我们严格的测试这些更改，以预测问题并提供最佳性能，但是不能替代真正世界的代码。我们需要你的帮助，所以请安装Preview5, 用你强大的解决方案试一下，并通过使用IDE的Report-a-problem工具来告诉我们您的使用感受。

工作效率的提高

Visual Studio“15”也有很多旨在提高工作效率的特性。

代码编辑

智能感知过滤现在在C#, VB, C++工程中可用了。当尝试复杂的API时, 你可以将范围缩小到你需要的类型（例如，只是方法、属性或事件）。在C#和Visual Basic中，我们确定所需的“目标类型“，在匹配该类型的列表中预选条目。这个加速了你的输入，也减轻了必须在给定位置上找出预期类型的负担。

在C++中，实验的“预测IntelliSense”功能显示智能感知结果筛选的列表，所以你不需要在很长的列表中滚动。根据需要的可能性，只有期待类型的项目被列出。你可以在工具->选项->文本编辑器->C/C++->实验下打开这个功能。

在XAML中，我们已经添加了智能感知X:Bind。 当你尝试绑定属性和事件时，它提供了一个完整的列表。如果引用到的命名空间已经存在，命名空间会自动补全前缀。XAML智能感知也已经更新，以筛选出类型和属性不匹配的。选择最接近的匹配，所以你只看到相关的结果，不必滚动一长串的类型列表。

在JavaScript中，我们已经完全重组语言服务以增强智能感知功能。以前，当键入时，JavaScript 引擎连续的执行你的代码来提供运行时的完全列表和签名帮助。对于静态的JavaScript代码来说，这个非常好，但是它经常提供不一致的编辑体验。新的语言服务使用静态分析，由TypeScript提供更多详细的智能感知，覆盖ES6/ES7，以及更一致的编辑体验。

快速修复和的重构

为使代码可读，并促进您的开发工作流程，我们已经为C#和Visual Basic增加了快速修复和重构。Move Type to Matching File移动类型到一个新的有相同的名字文件。Sync File and Type Name可以重命名类型以匹配你的文件名(反之亦然)。最后，转换为差值的字符串融合了C#6.0和VB14的优点，通过把你的’string.Format’转换为插值字符串的表达式。

代码导航

当你面对一段庞大的代码时，想确定你在哪块是一项有挑战性的工作。微软增加了一些新的导航功能，可帮助与此相关的操作。“转至”（按Ctrl+, 或Ctrl+T）可以让你快速找到你代码中的文件，类型，方法，和其他类型的对象。

现在即使是在复杂的代码库中，也可以很容易的帮助你查找到所有的引用（Shift+F12）。在搜索结果中它提供了先进的分组、 筛选、 排序和 （对于某些语言） 彩色化显示，以便你清楚地了解那些引用。

调试

在 Preview 5 中，我们引进了此实验功能：Run to Click。您不再需要设置临时断点，来跳到并停止到你需要的代码所在位置。当调试器停止时，只需点击在你的鼠标悬停时，出现在代码行边上的那个图标。您的代码将在下次运行时，命中该行并停止。您可以在这里启用该特性：调试>选项>启用 Run to Click。

尝试一下

对于在此版本的完整列表，以及一些已知的问题，查看 Visual Studio “15” Preview 5 Release Notes页。

关于Preview 5的几个重要的说明。第一，该preview版本是不提供客户支持的，所以不要在有非常重要工作的机器上安装它。第二，Preview 5可以和Visual Studio之前的版本一起工作，但是在你开始安装过程之前必须删除掉之前安装的任何Visual Studio 15预览安装。对于其他常见的问题，请查阅Preview 5 FAQ。

一如往常，我们欢迎您的反馈。对于问题，请通过安装程序或者IDE本身的“报告问题”选项让我们知道。并且可以在开发论坛上跟踪您的反馈。对于建议，请通过UserVoice让我们知道。

最后，请浏览今天早些时候Mitra发布的帖子，去了解即将到来的2016年的开发者大会。]]> https://docs.microsoft.com/archive/blogs/visualstudio_cn/visual-studio-15-%E4%B8%AD%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88%E5%8A%A0%E8%BD%BD%E6%97%B6%E9%97%B4%E6%9B%B4%E7%9F%AD Wed, 25 Jan 2017 09:09:15 GMT https://blogs.msdn.microsoft.com/visualstudio_cn/?p=2015 [原文发表地址]: Shorter Solution Load Time in Visual Studio “15”

[原文发表时间]: October 11, 2016

Selma之前分享了一些使visual studio “15”启动比以前更快的方法。今天，我会讨论visual studio “15” 中的一个新功能叫做轻量级的加载解决方案。这个功能极大减少了解决方案加载时间，所以你可以更有效率更快地使用IDE。

轻量级加载解决方案

当启用轻量级加载解决方案，Visual Studio 不会完全加载项目，除非你开始使用它。许多常见的任务，例如通过您的代码库导航，编辑代码，和编译您的项目将不需要加载所有项目。

为了了解在真实的场景中它是如何工作的，我们在容量有限的 Visual Studio “15”preview 4 上发布了轻量级加载解决方案。目前看来，这些性能改进效果还是不错的：

在推出这个有限的功能之后，我们发现解决方案加载时间加快了两到四倍。

此功能的最终目标是使您在IDE中更加高效的工作。使用轻量解决方案加载的开发者们能够在浏览或者编译他们的代码时快1到2分钟。我们也期待在Preview5 中这一特性能够被更完整地发布。

试试它

轻量级的解决方案加载在Preview5 上并不是默认启用的，但我们想鼓励开发者们在中型到大型的、或托管解决方案中尝试这一功能并给予反馈。启用轻量级的解决方案加载，可以在导航菜单中选择工具->选项，然后选择项目和解决方案->通用，再勾选页面底部的‘轻量级解决方案加载’：

一旦启用了轻量级解决方案加载，你可以像往常一样打开并操作你的项目和解决方案。设置将在你下次加载解决方案的时候生效，没有必要去重启IDE。

在Preview5中轻量级解决方案加载主要作用于托管项目。若你在处理中型或大型的C#或VB的解决方案，我们强烈建议你试用这一新特性。你也能够打开C++或其他项目类型的混合解决方案——但请记住，对于其他类型的项目（更多信息见下文*）而言，目前还不是所有性能的提升都是可用的。

当轻量解决方案打开后，你或多或少能够像往常一样继续你的工作，只是会更快一些。特别地，还有一些事你可以试试：

• 用Navigate to（Ctrl+，）浏览你的代码库定位，查找声明定义（F12），查找文件，或查找所有引用
• 重构代码或内联重命名
• 生成或调试您的解决方案

你可能会注意到一些操作花了一些时间在后台加载项目数据。

请注意，轻量级解决方案负载仍然在试验中，所以它仍有一些不足之处：

• 如果一个关于项目的功能从IDE中丢失了，请尝试在解决方案资源管理器中扩展项目。如果有任何不能正常工作的情况请告知我们。
• NuGet包恢复至今仍未与轻量级解决方案负载集成，我们建议在打开功能之前恢复包打开之前的功能或用命令行恢复。
• 除非一个项目完全被加载，否则测试浏览器不会看到测试结果。
• 如果你需要在一个解决方案中重定向或升级所有项目，禁用轻量级解决方案负载效果会更好。

*虽然在Preview5中轻量级解决方案负载作用于托管项目，如果你是一个C++开发者 也请不用担心，在未来的Preview5中有很多关于C++的性能改进，——在周四查看本系列的第四部分可以获取更多细节。在将来的版本中，这些改进将纳入轻量级解决方案加载。

请给我们反馈！

我们很乐意听到您使用轻量级解决方案加载的经验反馈。如果您在运行中遇到任何问题，可以使用在 IDE 右上角的"报告问题"的工具，让我们知道。对于性能问题，如 IDE 加载很慢或不响应，请使用报告问题工具向我们报告问题。此指南链接到一个工具，它会自动收集我们诊断性能问题时需要的踪迹和其他信息。

如果你使用大型代码库，并乐意与我们分享反馈关于你的经验，请考虑填写这份简短调查，包括您的联系方式和有关开发的类型的一些详细信息。您的反馈可以帮助我们尽可能提供最好的开发体验。]]> https://docs.microsoft.com/archive/blogs/visualstudio_cn/visual-studio-15%E5%90%AF%E5%8A%A8%E6%9B%B4%E5%BF%AB%E4%BA%86 Wed, 25 Jan 2017 06:28:31 GMT https://blogs.msdn.microsoft.com/visualstudio_cn/?p=1945 [原文发表地址]: Faster Visual Studio “15” Startup

[原文发表时间]: October 10, 2016

正如John上周三在预览版5发布的博客中提到的，我们在这个版本中进行了大量的性能改进。这是包含Visual Studio “15” 性能改进的五部分系列的第一部分。

今天，我将向您介绍一系列我们为改进Visual Studio启动体验而进行的投入，主要包括以下方面：

• 使用我们的新性能中心，您如何确定所使用的扩展或者工具窗口是否影响了启动、解决方案加载或代码编辑等方面的体验。当然，还有如何优化它。
• 如何使用按需加载方法将扩展移出启动路径，优化和推迟缓存初始化，来有助于我们改善启动时间。

近年来，随着Visual Studio用户群的增长，在Visual Studio中也融合了一些合作伙伴的技术。 不幸的是， 由于这些功能在启动时会自动加载，这极大地影响了Visual Studio的启动时间。

下面是一个示例，显示了Visual Studio启动时间在启动加载扩展时，如何轻松地减慢50％。

Visual Studio启动包含什么？

有三个不同的Visual Studio 启动类型：

1. 首次启动：安装完成后第一次启动Visual Studio。 第一次启动Visual Studio比其他启动要慢得多，因为Visual Studio环境配置了各种缓存和预构建的表。
2. 正常启动：我们将在第一次启动后，后续的Visual Studio启动，称为正常启动； 此类启动不包括调试实例，或使用命令行参数启动的实例，以及之前安装的扩展或更新的实例。80％的Visual Studio启动都属于正常的启动。
3. 配置更改：在安装扩展或更新后发生的启动。

这些类型帮助我们识别潜在减速的根本原因，有利于进一步调查优化方案。

首次启动的改进

在Visual Studio 2015中，首次的启动包括扫描安装的组件和创建一个配置文件，初始化默认设置，获取用户登录信息，并初始化缓存，如托管扩展框架（MEF），扩展管理器，工具箱以及字体/颜色缓存。

在Visual Studio“15”中，我们已经考虑了每个步骤，以查看哪些可以延期或优化：

• 我们尝试在Visual Studio 2015中推迟工具箱的初始化，这对于加载时间有积极的影响，于是在Visual Studio“15”中就进行了这种更改。
• 一些缓存，如字体和颜色缓存不再在第一次启动时初始化。 我们改进了缓存配置，使我们可以推迟其初始化，而不会影响首次启动时的用户体验。
• 通过使MEF和扩展管理器服务异步，我们现在可以在登录运行时并行初始化这些缓存。

有了所有这些变化，我们很高兴地宣布，Visual Studio“15”的启动速度比Visual Studio 2015快3倍。这是一个从我们之前的遥测获取的数据：

正常启动的改进

Visual Studio的正常启动，至少需要初始化核心服务。 每次发布我们都会继续监控这些服务，以确保核心初始化不会变长。 除了核心服务之外，启动时间还会受到两个因素影响： 在启动时自动加载的扩展和在先前实例的窗口布局中保留的工具窗口。我们的遥测结果表明，自动加载 Microsoft和第三方的扩展项，会显著增加Visual Studio启动时间。

如上所述，我们在Visual Studio“15”中的主要重点是避免自动加载扩展，并为这些扩展提供更多选项，以便稍后再加载而不影响用户体验。作为这项工作的一部分，我们提供了以下功能：

• 启用对Visual Studio软件包的异步加载支持
• 扩展中间数据规则来控制自动包的加载和命令的可见性
• 支持核心Visual Studio服务的异步查询

Xamarin和Python工具是第一个在Visual Studio“15”中采用按需加载方法。 你现在应该看到启动是相当快的。

影响启动的另一个因素是在启动时在IDE上可见的工具窗口。 这些工具窗口与之前的实例一致，并且加载这些工具窗口所增加的时间，取决于它们初始化的功能的大小; 其中一些是相当明显。我们继续专注于基于我们的遥测技术提高这种工具窗口的性能。 此外，“管理Visual Studio性能”对话框帮助您覆盖这些工具窗口的默认持久性行为。您将在下一部分中了解到有关此对话框的更多信息。

监控扩展和工具窗口性能

我们在最小化启动时自动加载功能的需要的同时，还在Visual Studio“15”中添加了一个功能，以帮助用户了解他们的扩展和工具窗口以及解决方案的加载和编辑等场景对启动的影响。是的，此功能会自动加载以监视Visual Studio启动时发生的情况。

当您启动Visual Studio时，对于较慢的扩展，您将收到一个相关扩展的性能对启动的影响的一次性通知。

在任何时候，您可以通过帮助 - >管理Visual Studio性能打开对话框，查看哪些扩展或工具窗口影响您的Visual Studio的启动，解决方案加载等。从“管理Visual Studio性能”对话框中，也可以禁用扩展。

与扩展一样，您可以在同一对话框中查看工具窗口对启动速度的影响。 如果工具窗口明显减慢了Visual Studio的启动速度，您也会收到通知。 您可以通过以下两个选项之一进行选择来覆盖默认持久性行为：

• 使用默认行为; 对当前行为没有改变。 因此，如果您选择此选项，那么启动时间不会有所改进。
• 启动时不显示窗口; 工具窗口永远不会在实例之间持续。 您可以稍后从菜单中打开它。
• 启动时自动隐藏窗口; 如果在启动时可以看到工具窗口，则此选择将折叠其组来避免初始化工具窗口。这个选项是我最喜欢的。

您可以通过返回“管理Visual Studio性能”对话框并将选项更改为使用默认行为来恢复这些选项。

持续帮助我们

虽然这篇文章专注于启动改进，但我的同事Will Buik将在下一篇文章中谈到解决方案负载领域的重大改进。 这些更改应该允许Visual Studio在使用从Windows资源管理器中选择的解决方案打开时更快启动。

您可以在以下几个方面来帮助我们，以使Visual Studio成为更好的产品：

• 首先，我们监控所有发布的遥测，包括预发布。 所以请下载并使用 Visual Studio“15”预览5。
• 其次，如果你是一个扩展的创造者，请继续关注; 在接下来的几周中，我们将详细介绍扩展创造者如何分析其扩展。 因为任何选择在启动时或解决方案正在打开时自动加载的扩展都会对Visual Studio的性能产生负面影响。 即将推出的指南将有助于评估Visual Studio“15”中的新功能是否可用于删除自动加载的需要或减少自动加载的影响。 对于需要自动加载的扩展，指导还将帮助衡量对启动的影响。

谢谢！

Selma]]>