Visual Studio “15”响应速度更快
[原文发表地址]: Improved overall Visual Studio “15” Responsiveness
[原文发表时间]: October 14, 2016
这是包含Visual Studio “15” 性能提升5部分系列的最后一篇博客了。
这个系列中包含了下边的内容：
· 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变得更好的任何问题吧。