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

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次。