Visual Studio -- working on performance

Jason has a new posting on the progress of Visual Studio and I wanted to chime in myself. Some people have been wondering what I’ve been up to… I think you’ll be happy to hear that about 2 months ago I put down a bunch of my long term planning responsibilities so that I could work on Visual Studio performance directly. Woo hoo!

So performance work: what kind of work? Well the most important thing I’ve been doing is helping people in VS to understand where the problems are, and how to make directed improvements that get locked in. I’ve been doing lots of training, I’ve been creating custom analysis tools for studying VS performance problems, and I’ve also been yelling at a lot of people and just generally making all kinds of friends in my division. :)

During these last weeks we’ve made a lot of progress, I’m sure you’re going to feel the product is a lot snappier than the builds we provided at the PDC. But of course I’m never satisfied – there are even more wins coming later. I worked with many different teams to help us with our startup, with UI transitions, with memory usage, with threading issues – especially with how WPF and our main thread synchronize. This very morning I’m busy reviewing goals for every major group in Visual Studio and we’re working hard to create a great experience. I’m especially happy with the changes that will benefit many applications (like some of the ones that are finding their way into WPF, or interop)

So, especially for the next big push before release, performance will be a very high priority for Visual Studio – I’m going to be very pleasantly busy.

What does this all mean to you? My blog is now a great place to give your feedback, especially on the Beta when it comes out. Tell me what is hurting you the most, many people will be watching, including me, and we still have time to get attention on key problems. I'd love to hear about it.

Comments

• Anonymous
  May 14, 2009
  Updatating good old WebReferences is much slower in VS2008 than in eg. VS2003.

• Anonymous
  May 14, 2009
  I've not played with the (old) beta yet, but from the VS 2008 product, the two biggest performance issues to me are the Add Reference dialog and running unit tests.  Fix those, and you'll have a lot of very happy customers.

• Anonymous
  May 14, 2009
  I always found that getting latest from source control always took ages and stalled VS while it was waiting... would love an improvement to that!

• Anonymous
  May 14, 2009
  The comment has been removed

• Anonymous
  May 14, 2009
  Hi, I am a developer for headup.com We develop mainly in Silverlight, and I have to say that since I have installed Silverlight Tools on my computer Visual Studio has become much slower than usual. It's great that you guys are working on performance, especially because we developers don't have a lot a patient:) Are you checking the performance of the Silverlight Tools as well? What makes these tools so heavy? Thanks anyway, and you are more than welcome to check headup.com out.

• Anonymous
  May 14, 2009
  Thank you for submitting this cool story - Trackback from DotNetShoutout

• Anonymous
  May 14, 2009
  I agree with the earlier comments. "Add Reference" is one of the slowest performing parts of the UI. Improving that would be a good start :-)

• Anonymous
  May 14, 2009
  It would be great if "Add Reference" opened (the first time) on one of the tabs the doesn't take an age to populate. I usually want to add a reference to a file in the file system (i.e. use the "Browse" tab), as we've got a dependency management system as part of our build, and we specifically don't want to reference "whatever version is installed". That usually means:

• Click "Add reference"

• Wait for the ".Net" tab to populate (sometimes > 60 seconds)

• Switch to "File" tab and navigate to the file (very quick). While I'm here... I believe you've got a new help viewer system, right? Hopefully your looking at the startup time for that, too. If I hit F1 in VS2008, MSDN takes an absolute age to start on my system for some reason. VS is locked until the MSDN window comes up, too. :-( Cheers, and keep up the good work!

• Anonymous
  May 14, 2009
  Working with a large amount of tests is extremely slow in Visual Studio 2008 Team Suite (including SP1). Specifically the testview & testlisteditor makes VS freeze for many minutes when it collects tests(even >10 minutes on slower machines), reproducible on many machines. We have a solution with 6 projects, containing a few thousand tests (mostly unit-tests but also a lot of webtests) and a dozen loadtests, referring to those tests. Analysis with profiling tools and full trace logging on VSTS pointed at inefficient code in Visual Studio QualityTools.

• Anonymous
  May 14, 2009
  A very annoying 'feature' is still the first time loading help (pressing F1). It takes many minutes and in the mean time it blocks Visual Studio. Please make sure that loading help doesn't block VS anymore.

• Anonymous
  May 14, 2009
  starting the exception dialog (ctrl-alt-e) to make the debugger stop at any exception takes easily 10s. as i am only using this dialog to globally break at 1) all or 2) no exceptions i would be happy to get a toolbar button for that.

• Anonymous
  May 14, 2009
  and: when can we expect the next beta? how else can we judge performance?^^

• Anonymous
  May 15, 2009
  So far I have been very impressed with the CTP builds of Visual studio 2010 . There are some really welcoming

• Anonymous
  May 15, 2009
  The comment has been removed

• Anonymous
  May 15, 2009
  I remember a few years back I was in Mark Anders office.  He was working on the next gen IDE.  I told him if he could match the response time of notepad, he'd rule the world.

• Anonymous
  May 15, 2009
  One area I'd love to see a focus on is speeding up compiling, especially for ASP.NET + class libraries.  It often takes nearly a minute to compile and validate on a decent size project, even on a modern machine. One thing that could help make the compile time less of an issue is if you could continue to have a responsive UI to browse/edit the code even while a compile is going.

• Anonymous
  May 15, 2009
  Good to know that VS 2010 performance is in good hands :)

• Anonymous
  May 15, 2009
  Is there any optimization being done specifically for native C++/Win32 UI and Editor responsivness? (resource editor, code editor, wizards)

• Anonymous
  May 15, 2009
  The comment has been removed

• Anonymous
  May 16, 2009
  Rico, nice to hear all these. You have an easy perf killer scenario to address for VS2010: 'Copy Local = true' I give details in the following blog post and showed to the NUnit team how to divide their compilation time by 3 by removing 'Copy Local = true'. http://codebetter.com/blogs/patricksmacchia/archive/2009/01/11/lessons-learned-from-the-nunit-code-base.aspx Stop promoting 'Copy Local = true', really, in the real world I can tell you that the damage are very big.

• Anonymous
  May 16, 2009
  One more vote for "Add Reference". Usually I have to add one or more references to a library on disk or another project in the same solution. Still I have to wait 30-90 secs each time I open this dialog because the .NET tab is the default, that's really annoying. So if you don't get the list populated faster then please switch the default tab.

• Anonymous
  May 17, 2009
  The .NET tab is a reasonable default for beginners. What is a fair compromise is making the default tab a parameter that can be stored in the vs settings file.

• Anonymous
  May 18, 2009
  This is great, Rico should always be involved in any VS build, performance should always be a top priority! VS2010 will be amazing, I can feel it :)

• Anonymous
  May 18, 2009
  I have found it bad in the past when I update my code from source code control (external to msdev), then msdev spends forever asking me (one file / project at a time) if I wish to reload the item. Msdev seems to update a lot of its internal state for each item it reloads, rather then waiting until it has reloaded all project files before doing the update.  This is very slow when 10s of projects files have been changed in a solution. Also sometimes when I exit msdev it takes forever, I think this is when msdev is paged out, and it touches a lot of memory on exit.

• Anonymous
  May 19, 2009
  @Z-Bo: that's the lazy way out. Why not have the tab load the assembly data asynchronously, so you can switch to "File" immediately if that's what you want? This would already solve 90% of the issue; the remaining 10% is speeding up the retrieval itself (where caching can make good, as how often does the contents of your GAC change?) It's a basic tenet of UI design that you keep the interface responsive, no matter what you're doing under the covers -- so if it's going to hold up the interface, do it in the background and update periodically. VS is actually pretty good at adhering to this principle, with the "Add Reference" dialog as a glaring exception.

• Anonymous
  May 19, 2009
  I've just waited 20 seconds for the add-reference dialog to appear on Beta1, so I guess if there's any work being done there, it's not been released yet. In creating a test project to try the references dialog, the file menu took about 10 seconds to appear, and the new project took about the same again. There's no 'help' in B1 at all - it just opens a browser on an MSDN page - I guess that was a reasonable way of avoiding that performance issue. I can't actually see myself really using B1 yet, with its fuzzy menus, no VisualAssist, no Resharper and no MVC - not really sure how much feedback MS get from these non-go-live betas.

• Anonymous
  May 19, 2009
  Thanks for the post, good to know things will keep improving, anyway here're a few quirks about beta1: -PERFORMANCE while debugging heavily multithreaded programs is at least 1 order of magnitude worse than when the same program is not run from within the IDE (regardless on if/where breakpoints are set) -the Autos/Local/Watch1/Watch2 windows while performing the 1st debugging session with VS weren't displayed until I hovered with the mouse the area where their label was supposed to be. -sometimes I won't get the solution explorer window displayed until I close/reopen the solution -I've experienced several crashes in a relatively short timeframe (running on win7 RC) and promptly sent reports for those

• Anonymous
  May 19, 2009
  The comment has been removed

• Anonymous
  May 19, 2009
  Sorry to post so much, but after 1day of usage I now get a message stating that the intellisense sdf file can't be created and that intellisense will be disabled each time I try to open a VC++ project. Tested with Full Control set for Everyone, too, with no luck. The weird thing is that until yesterday intellisense worked just fine  and no changes were made...

• Anonymous
  May 20, 2009
  One of the things that's killing us on our project right now (we're on VS2008 SP1 and VB.NET) is MSTest.  We have almost 1000 unit tests in a solution of about 24 projects and reloading the test list is horrible.  There are times when Visual Studio will lock up for minutes at a time while it refreshes the test list (that's our best guess as to what it's doing based on attaching a debugger to devenv.exe and seeing what thread stacks look like).  We've enabled a Registry setting that we found referenced in the MSDN forums which helps a bit (EnableCMI) but there are still times when Getting Latest from source control where VS will lock up for long periods of time (getting latest over a local network is in the order of 10-15 minutes... most of which appears to be spent on that test list update).

• Anonymous
  May 20, 2009
  At Microsoft you can't say you're excited about anything you have to say that you're "super excited". 

• Anonymous
  May 20, 2009
  Count my vote for Add Reference as well :)

• Anonymous
  June 03, 2009
  Another vote for the Add Reference dialog.  One relatively simple improvement would be, after the Add Reference... context menu item, an Add Project Reference... context menu item that would go straight to the Project Reference tab, skipping populating the insanely slow .NET GAC tab.  (I've suggested this on Connect, but it didn't seem to go anywhere.)

• Anonymous
  June 07, 2009
  Hi I'm still using VS2008. I have Created an Test Project using MS Pex (http://research.microsoft.com/pex), and since I have that Test Project, my VS crashes most of the time. It sometimes takes over 1h to load the testlist. But that's not the only thing I'm experiencing. Only loading the Project is sometimes enougth, to crash VS (OutOfMemory) or shows other errors (can't redraw the toolbars any more/red crosses). Well I haven't tried the VS2010 RC yet, but I hope these these Problems are fixed in it, at last before the final.

• Anonymous
  June 10, 2009
  The comment has been removed