Visual Studio 终于开始关注性能问题

Visual Studio 的性能问题一直以来都让人们头痛不已，且在各个版本中有越来越差的趋势。在一些小的项目中，这类性能问题并不会带来太大问题，不过若是解决方案中包含很多项目，或者是解决方案中包含着一个大型项目的话，性能问题将给开发带来很大影响。

在 Channel 9 的一段采访视频中， Cameron McColl 对微软公司未能完整测试大型项目中的 Visual Studio 性能问题表示了道歉。随后 Cameron 介绍了现有的一些典型性能问题，并给出了 Visual Studio 2008 中针对这些问题的解决方案。

Cameron 提到的第一个问题就是单步调试代码时的性能。很多.NET 开发者都遇到过这类问题——每一行代码的单步调试都可能会带来 5-10 秒的延迟。 虽然这种情况并不是特别常见，不过在出现时却非常让人沮丧。Cameron 并没有提到过于深入的细节，不过据称这并不仅仅是 Visual Studio 的问题——操作系统现存的一个缺陷也为每个单步调试添加了额外的一秒钟延迟。对该问题的补丁将在 VS 2005 Server Pack 1 和 Visual Studio 2008 中给出。

Cameron 提到的第二个问题就是在输入代码时，Visual Studio 可能会突然间失去响应一段时间。导致这个问题有很多原因，其中一些已经被修复。其中一个原因就是包含了错误、警告和 todo 的任务列表。当任 务列表被修改时，其中所有的项目都将被移除，然后再重新添加。这样重复计算滚动条位置的实现逻辑给性能带来了很大的影响。

另外一个原因则与 VB 的后台编译器有关。后台编译器给 Visual Basic 带来了非常强大的设计期支持，例如即使的代码完成以及错误检测功能等。C#和 C++ 等语言并没有这个功能，因此为了了解当前的代码结构，开发人员有时将不得不需要重新编译项目。

不过后台编译器所带来的负面影响在于，当 Visual Studio 打开某个解决方案时，需要等待后台编译器的运行。对于大型项目来讲，这个问题尤为显得致命。作为解决方案，当类型和列表的信息尚未完成时，显示这部分内容的下拉列表框将会被暂时禁用。

另外一个问题就是，Visual Studio 允许开发人员取消某个长时间的操作。若某个操作需要从后台编译器获取信息，那么 IDE 在显示出进度条和“取消”按钮之前只好等待一段时间。

另外一个问题就是在开始编辑大型 Web 应用程序中的 aspx 页面时，将会有一段明显的延时。与代码编辑器类似的是，发生这个问题的原因也是 IDE 在等待后 台编译器。现在的解决方案是代码编辑器将立即启动，不过代码高亮和自动完成功能将暂时无法使用，直到后台编译器完成其工作之后。

Cameron 所提到的最后一个问题是有关编译的。对于某个包含了 25 个项目、大概 3000 个文件的 VS 2005 项目，一次重新编译将花费大概 45 分钟的时间。不过在 VS 2008 种却只要 1 分钟就够了。为什么会这样呢？因为在 VS 2005 中，若某个项目被其他 N 个项目所引用，那么该项目则将被重新编译 N+1 次。

查看英文原文： Visual Studio to Finally Address Performance Issues