Visual Studio 2008 Performance: Still Room for Improvement

Across the Developer Division, we have made a concerted effort to make Visual Studio 2008 the best performing and most scalable version of the application yet. (See Soma’s Blog entry from September 2007 for some of the details.) We’ve already had lots of positive feedback about these improvements, which is gratifying because we are working hard at this. However, not all the feedback on performance we get is positive. We know that there is still a long way to go, and we are executing on a long term plan to keep improving the performance of our products for VS 2008 and beyond. In the meantime, we want to keep hearing from you about any performance problems you encounter to gain a better understanding of the areas that still need improvement.

In this blog entry, I thought I would highlight some of the known VS 2008 performance issues that are currently resolved and for which fixes are available. We will also mention some serious problems that we know about and are currently working to resolve, but do not yet have fixes available. Finally, we will discuss the procedure to use if you have a VS 2008 performance problem to report. We want your feedback, and we want to streamline the reporting process as much as possible.

VS 2008 performance Hot Fixes:

There are three hot fixes available for some specific VS 2008 performance problems. If you are currently experiencing a performance problem with Visual Studio, it may be one we have a fix available for. To access the fixes, go to the Visual Studio Connect site, then click on Hot Fixes and scroll down to see the ones associated with Visual Studio 2008. The hot fixes with a performance flavor we recommend that you review are the following:

Download Link

Problem Description


The Visual Studio 2008 IDE runs slowly when you are trying to build a Visual Basic project that contains large numbers of XML comments in a single file. Note that the file is often designer-generated for a dataset or for a Web reference. Follow the KB946344 - More Informationlinkfor details.


The Visual Studio 2008 IDE runs slowly when you are editing HTML, editing Javascript, building a web site, or issuing the View Code command. Follow the KB946581 - More Information  linkfor details.


Fixes a performance problem in the debugger when you are stepping through source code that is downloaded from Microsoft Reference Source Server that was caused by downloading the source files again for each breakpoint. Follow the KB944899 - More Information  linkfor details.


Known VS 2008 performance problems;

There are also some performance problems that we are developing fixes for at the moment.

· Editing complex ASPX pages (with lots of nesting) can be slow (especially those that use Multi-View controls).

· Large numbers of controls in the toolbox and/or a large number of AJAX extenders can slow down switching between design and the Web form view.

· If your code references an assembly that’s not present (or the wrong version), you’ll see an error in the errors window and performance will be negatively impacted until the situation’s corrected.

Of course, we will let you know as soon as there are fixes available for these reported problems.

How to report a new VS 2008 performance problem:

If you are experiencing a performance issue with VS 2008 that is not among the ones discussed above, we’d like to know about it. Here’s some of the information we need from you to help identify the problem so we can find a solution quickly.

When you report a VS 2008 performance problem, please tell us which Visual Studio edition (and version) you are using. Also, what VS 2008 add-ins and/or 3rd party controls, if any, are you using? BTW, you can just send us a copy of all the add-in and patch information directly from the Help|About dialog box.

In addition, we’d like to know the following:

· What type of projects(s) are you building (Web App, Winforms, WPF, ...)?

· What languages (C#, C++, VB, ...)?

· Is the performance problem with VS or with the code it generates?

· How large is the solution? # projects? # of files? Size of largest file?

· What’s the system configuration?

Also, it always helps when you tell us in detail what you are doing when the problem occurs, including:

  • Can you quantify ((roughly) the performance problem? (For example, it takes 10 minutes to do this, and I think it should take 10 seconds.)
  • Do you only see the issue with one specific solution or many?
  • Can you tell if performance appears to be limited by Disk, Network, or CPU performance? For example, does the CPU busy indicator in Task Manager spike to 100% when you experience the problem?


Most important of all, we need to know if you can reproduce the problem consistently. Please document the steps that need to occur to re-create the problem you are experiencing. If not cannot describe what you were doing step-by-step, at least provide us with an outline of the actions or activities that need to be performed to re-create the problem. In addition, we may like to know the following:

  • If the problem occurs consistently using a specific project, are you able to send us a copy of that project so we can reproduce the problem?
  • Would you be willing to run a tool that we will send you that will collect performance profiling data when reproducing the issue to help us to understand what is happening?

There are lots of ways to reach us to report a Visual Studio performance problem:

1) You can log bugs on Connect. Bugs logged there go directly into our bug tracking system and Connect provides a mechanism for communication, tracking, status, as well as enabling other customers to comment.

2) You can e-mail the Performance Team directly at

3) You can post comments on this blog.

David Berg

Senior Program Manager

Developer Division Performance Engineering Team

Microsoft Corporation