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
KB946344	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.
KB946581	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.
KB944899	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 DevPerf@Microsoft.com.

3) You can post comments on this blog.

David Berg

Senior Program Manager

Developer Division Performance Engineering Team

Microsoft Corporation

davberg@microsoft.com

Comments

• Anonymous
  April 28, 2008
  I think you are missing the most important and annoying of all! https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=327222

• Anonymous
  April 28, 2008
  The comment has been removed

• Anonymous
  April 28, 2008
  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. Thanks. Mark Friedman Sr. Architect Lead Developer Division Performance Engineering

• Anonymous
  May 02, 2008
  The comment has been removed

• Anonymous
  May 04, 2008
  rkpatrick, 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

• Anonymous
  May 04, 2008
  The comment has been removed

• Anonymous
  May 09, 2008
  The comment has been removed

• Anonymous
  May 09, 2008
  The comment has been removed

• Anonymous
  May 19, 2008
  The comment has been removed

• Anonymous
  May 19, 2008
  rkpatrick, Let us know how it goes.  

• Anonymous
  May 29, 2008
  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)

• Anonymous
  May 29, 2008
  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.

• Anonymous
  May 29, 2008
  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.

• Anonymous
  May 29, 2008
  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.

• Anonymous
  May 30, 2008
  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.

• Anonymous
  July 09, 2008
  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.

• Anonymous
  July 10, 2008
  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)

• Anonymous
  July 11, 2008
  The comment has been removed

• Anonymous
  July 11, 2008
  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, Dave

• Anonymous
  July 13, 2008
  Zzz, 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 (http://msdn.microsoft.com/en-us/library/bb651793.aspx). Improving intellisense is a big focus for the C++ team (see their blog for a discussion on their plans). Regards, Dave