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 Information link for 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  link for 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  link for 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

Comments (20)
  1. jabbera says:

    I think you are missing the most important and annoying of all!

  2. rkpatrick says:

    The one that has consistently drove me absolutely bonkers since VS2002 (unfortunately, I can’t try it at work as only my home PC has 2008) is the lack of responsiveness of the Cancel Build button. Maybe 1 out of 3 times that I need to use it, the IDE is so busy building that it won’t pick up the click; on those occasions where it does respond with a click, it actually succeeds in stopping the build maybe 1 out of 5 times (failure isn’t due to the build finishing before I click…it just doesn’t pick up the command at all)

    I only see this on large projects (and it may only be restricted to ASP.Net projects), incidentally, as smaller ones build too quickly to need the cancel feature

  3. Thanks for the feedback.

    We are quite aware of both problems. In both cases, architectural solutions are required, so it is not a simple fix, unfortunately.

    In the case of Cancel Build, there needs to be communication added between the IDE thread and the whole Build process, which currently ties up the main UI thread so no "Cancel" message can be posted. We are working on a fix.

    In the case of Solution Explorer, there is also a fix in the works, as well as additional longer term architectural changes to the Project system to ensure it scales to very large solutions & projects.

    Hey, we care about this stuff, too, so keep those cards and letters coming. It helps us to hear from you.


    Mark Friedman

    Sr. Architect Lead

    Developer Division Performance Engineering

  4. rkpatrick says:

    Couple more that come to mind (although again, I can only verify it’s in 2005 and has been around for several versions);

    1. The dreaded "Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation" debugger error. I currently get this on a small WinForms app I run every time an exception gets hit, so I have to kill program execution, put a try/catch around it that dumps out hte stack trace, and then re-run because the debugger is effectively dead at this point. I’ve gotten this before on other projects; once the IDE starts doing this, it doesn’t stop and in fact gets worse and worse, even after rebooting the machien.

    2. Integration with VSS can lock up the IDE; my company network has enormous lag to the VSS server, which makes VSS basically useless. However, it even extends to VS, because source control integration is so tight, the entire IDE hangs while it tries to get status on every single source-controled file (hundreds of them in my case)

  5. David Berg says:


    In VS2005 (and earlier) the main cause of functions timing out in the debugger was thread switching (which could be triggered by something as simple as accessing a WinForms property in the wrong context).  Since all other threads were stopped, the system would hang until it timed out.  In VS2008 we eliminated this issue by hooking thread switching calls (when in debugger expression evaluation) and failing them immediately.  So the likelihood that you’ll encounter that particular problem should be substantially reduced.

    Unfortunately most applications, including VS, deal poorly with slow / unreliable network connections.  For now, the best you can do is either fix the lag or disconnect entirely from the network (both of which have their issues).  Long term, we need to do a better job of designing applications to deal with the wide ranges of network performance.

    David Berg

    Developer Division Performance Engineering Team

  6. David Berg says:


    We’re continuing to work on getting hot fix KB 947751 posted publically, probably within the next week or so.  As noted in the connect bug you linked to, it is currently available for those calling in.  


    David Berg

    Developer Division Performance Engineering Team

  7. rkpatrick says:

    David, do you know if the function timeout fix that went into 2008 gets rid of issues where the timeout causes executing threads to die? I’m working on a project right now that copies millions of rows of data selectively across servers and have blown several hours trying to debug a particular issue due to the time it takes for the particular error situation to hit on top of the ensuing Local var view causing execution to crap out on me.  If the 2 hours or so it takes to install 2008 will save me 10 hours of (incredibly frustrating) debugging time, it’d be worth the downtime, but I’m hesitant to run through the red tape with the IT dept (admin install issues) if I’m stil stuck with an app that the IDE kills when looking at variable values.

  8. David Berg says:


    If you have watches or other expressions being evaluated in the debugger that require code to execute on a different thread than the one stopped, then you are going to see the timeouts in VS2005 and shouldn’t see them in VS2008.  That sounds like it might save you a lot of debugging time.  

    Of course, there’s no way I can know for sure if it will fix your specific problem without testing it.

  9. rkpatrick says:

    Yeah, I’m gonna have to bite the bullet and try the upgrade. I had hoped that by going to a low-latency network connection, the issue would go away, but it looks like it’s something intrinsic to the way Sql Mgmt Objects interacts with the IDE (it truly is a whole new class of horrible, to be quite blunt, but SMO is proving to be a nightmare to debug beyond just the timeouts), as my threads die even when I’m on the same server as the DB.

  10. David Berg says:


    Let us know how it goes.  

  11. rkpatrick says:

    So far, 2008’s been handling the SMO debugging very well. Not only are there no timeouts, but it’s actually showing the Locals window much quicker. Only downside (so far) is that I really can’t use it to work on my 2005 project; I know it can target 2.0, but the risk that it can still in some manner break the existing app is there (and on that policy, I have to agree, given that I’ve hit problems like that going all the way back to VS5.x)

  12. Hey, good to hear that the performance improvements at least are holding up so far.

    On the risk of converting 2005 projects to 2008, for what it is worth, my experience there has actually been pretty good, too. I was a customer, too, not too long ago, and I remember getting burned on an upgrade many times.

    There is at least one aspect of this release that is generally not understood that helps enormously with conversions. If you examine any of the assemblies associated with VS 2008, you will see that the library where core functions like System.Windows.Forms.dll, for example, reside is still v2. New functions have been added in v3.0 (WCF, WPF and Workflow) in the v3.5 libraries, but we deliberately haven’t made the kind of breaking changes to v2 modules that would impact a project conversion. For most practical purposes, in VS 2008 you are still riding on a similar version 2.0 Framework base.

    As a result, upgrading projects to VS 2008 should be largely transparent. It should be a much more benign experience than going between VS 2003, which targeted the Framework v1.1 to VS 2005 when the Framework 2.0 was introduced. There were lots of breaking changes between 1.1 and 2.0. You should see very little of that this time around.

    Good luck and keep the feedback coming. Thanks.

  13. rkpatrick says:

    MarkB: The catch is that the code I write with VS2008 should still compile on VS2005, as other developers use that IDE. As an example, when I moved my project over, I added a new class and instinctively (I use 2008 at home) added an automatic property. Project built fine, and everything’s gravy. However, I started to put a LINQ query into some code, and found I was missing Intellisense…long story short, I had forgotten to set the project to target 3.5 from 2.0. If I had put in an automatic property on some shared code rather than a one-off project and checked in, I would have caught an enormous amount of flak for breaking the build (and an email would have likely gone out lecturing the entire dev distribution list about ‘not supposed to…’)

    Needless to say, it seems good in theory, but in practice, I’ve already found areas that would have gotten me in trouble had I upgraded rather than side-by-side’d the two IDEs.

  14. I understand. If you use a cool new function, you create an immediate problem.

    But did the conversion itself work out OK?

    You really have to reach a point in the life of the project where most everyone in the team can move at the same time. In practice, this means sometime after you ship. You can’t afford to do it in the middle. Sometimes it is OK near the beginning.

    But after you ship, when the bug count is down and new bugs are coming in at rate that is under control, then you can think about moving.

    So, in the meantime, you are just going to have to stay away from cool new stuff like LINQ, which is an awesome achievement in my view.

  15. rkpatrick says:

    Yeah, the conversion itself worked great, and I’m having a much easier time without the debugger timing out (SMO tends to hit the DB for everything, so watches are slow, and almost every prop/method can throw). I do get some weird 2-3 second IDE hangs periodically that I didn’t notice in 2005, but I’m also working over RDP against a network with ~200ms latency, so it’d hard to blame that one on the IDE.

    I’d personally love for everyone to move over to 2008; it’s really streamlined a lot of my personal codebase (non-work-related) by removing 90% of my fields and constructors, plus I LOVE LINQ (especially PLINQ). Very pragmatic changes, which is how I tend to describe .Net if I need to use a single word, so it’s on a good track IMO.

  16. rkpatrick says:

    Well, unfortunately, the timeouts have come back under VS2008. Hadn’t had an issue with the SMO debugging under it for 2 months, but in the last 2 days, I’ve had 3 separate debug sessions end with the dreaded "Function cannot be evaluated…" messages on members of an exception I hit. My exception handler didn’t even get hit due to the thread dying, so after spending 15 minutes walking database objects, I have no idea what the cause is.

    Is there any way to turn off timeouts altogether? I’m not sure what 2008 considers to be an unacceptable amount of time to wait, but with SMO, property calls can take several seconds, but it’s not something that I want the IDE to assume is a failure of some kind that leads it to start terminating my threads.

  17. zzz says:

    I have modest c++/cli project (~800 .c 1450 .h) and it takes a good while (too long) to compile. I’m not feeling that the compiler is utilizing the cores effectively. There’s also noticeable disk activity during the compile but not as much to say it’d be entirely disk bound. The Intellisense thing builds quite slowly as well. This is a 3 Ghz Core 2 and 4 GB of memory.

    VS/CLR improvements I’d like to see:

    – CLR interop performance to go up

    – faster c++ intellisense building

    – have compile use more cores and less disk (load everything into the 4gb, compile in memory, after compile done, save stuff to disk, no disk access during compile)

  18. Mark Shiffer says:

    To rkpatrick:

    You are not the only one. The function evaluation timed out problem is quite consistently happening for me as well. I created a simple WinForm app with a button on it that creates a dataset with one table with 1 column and 1 row in it. Trying to bring up a visualizer on that dataset fails every time with the function evaluation error. It takes about 7 seconds for the error to come back. After attempting to continue execution the application hangs.

    In 2005 I had function evaluations from time to time, but I was usually able to continue execution. It actually seems to have gotten worse in 2008.

  19. David Berg says:

    rkpatrick and Mark Shiffer,

    Sorry to hear about the time outs.  I talked with Jim Griesmer on the debugger team and here’s what he said:

    "There’s a couple ways to handle this.  Turn off automatic property evaluation Tools->Options->Debugging.  This way the only time slow-evaluating properties will be hit is when the user specifically asks (by clicking the little refresh widget on a datatip or watch window).  The timeout for one of these evaluations is longer than for automatic evaluation – 10 seconds (rather than the normal timeout of 5 seconds).

    "Alternatively (or in addition) users can muck with the registry to increase the default timeouts:

    HKCUSoftwareMicrosoftVisualStudio9.0DebuggerNormalEvalTimeout = 5000ms

    HKCUSoftwareMicrosoftVisualStudio9.0DebuggerLongEvalTimeout = 10000ms

    "There’s also a datatip timeout and while I don’t think it really applies directly in this case, it could (user would have to select an “object.propertycall” in the editor and hover)

    HKCUSoftwareMicrosoftVisualStudio9.0DebuggerDataTipTimeout = 1500ms

    "The Immediate Window evaluation is also longer at 10 seconds:

    HKCUSoftwareMicrosoftVisualStudio9.0DebuggerImmediateWindowTimeout = 10000ms

    "The Quickwatch has the longest by default at 15 seconds:

    HKCUSoftwareMicrosoftVisualStudio9.0DebuggerQuickwatchTimeout = 10000ms

    "Of course, changing the registry values is a non-supported scenario."

    Hope this helps,


  20. David Berg says:


    I’m sorry to hear about your performance problems, and we appreciate the suggestions.  

    How long is too long?  How many lines of code / total project size (not just file counts)?  

    Loading everything into memory probably isn’t the panacea it might seem, but you’re right we do need to look at using memory more effectively.

    Which Operating System are you using?  (Note that Vista should do a much better job than XP at keeping all your files in memory.)  

    Unfortunately parallelizing C++ compiles is a longer term piece of business, but it is something that we expect to focus on in the future.  In the mean time, you might want to check out the new multiprocessor build capability in VS 2008 (

    Improving intellisense is a big focus for the C++ team (see their blog for a discussion on their plans).



Comments are closed.

Skip to main content