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 (35)

  1. Enrico says:

    Updatating good old WebReferences is much slower in VS2008 than in eg. VS2003.

  2. wekempf says:

    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.

  3. sparks says:

    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!

  4. Cat says:

    The VS2008 C# editor window takes seconds to process a single keystroke if a large (>3000 line) file is opened.

    I’d hazard that partial class support was added to C# just because of this problem.

  5. Eylon Yogev says:

    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.

  6. Thank you for submitting this cool story – Trackback from DotNetShoutout

  7. SimplyGed says:

    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 🙂

  8. swythan says:

    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!

  9. JK says:

    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.

  10. JK says:

    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.

  11. tobi says:

    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.

  12. tobi says:

    and: when can we expect the next beta? how else can we judge performance?^^

  13. So far I have been very impressed with the CTP builds of Visual studio 2010 . There are some really welcoming

  14. RJ says:

    The ‘Add Reference’ dialog is the pain in the ass. If you can fix nothing else, please fix this dialog.

    Thanks,

  15. JD Meier says:

    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.

  16. shawn says:

    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.

  17. Jazon says:

    Good to know that VS 2010 performance is in good hands 🙂

  18. Mister says:

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

  19. John "Z-Bo" Zabroski says:

    Hi Rico,

    I’m very interested to know whether you are working with the WPF Performance subteam on optimizations for the RichTextBox control, and whether such optimizations will provide any kind of performance increase for FlowDocument technology.

    As JD Meier says above, the big feature of any IDE is the "notepad" or text editor.  Yet, in previous versions of WPF, the RichTextBox control seriously drags in performance when the file gets larger than 1,000 lines.  In WinForms, it was a little bit better (although around 10,000 lines it started eating itself, but 10,000 lines is frankly crazy and only hit such line counts when doing data-driven tests).

  20. 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.

  21. Ooh says:

    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.

  22. John "Z-Bo" Zabroski says:

    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.

  23. abi says:

    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 🙂

  24. Ian says:

    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.

  25. JM says:

    @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.

  26. Will says:

    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.

  27. emaster70 says:

    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

  28. Martin MacPherson says:

    @Ian

    Yeah that performance issue has always bugged me.  One of our solutions has around 80 projects and if I get latest when the solution is open the fastest way to update is to click cancel when asked whether I want to reload each project. Once this has finished I then close and re-open the solution.  This is 10000x faster than clicking yes to reload each affected project.

    I’ve haven’t tried this in VS 2010 yet but my hopes aren’t too high…

  29. emaster70 says:

    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…

  30. Jeremy Wiebe says:

    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).

  31. At Microsoft you can’t say you’re excited about anything you have to say that you’re "super excited". 

  32. Justin says:

    Count my vote for Add Reference as well 🙂

  33. Kyralessa says:

    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.)

  34. Alexander Wurzinger says:

    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.

  35. tim says:

    What I would really like to see are some fully specified performance benchmarks.  

    For instance:

    " On <this OS/motherboard/HD/RAM/video combination>, which reflects the minimum recommended hardware for VS10, the help subsystem should typically respond to F1 within two seconds on first use and within one second subsequently.  The editor should be unresponsive for no more than 500 milliseconds"

    "On <an alternative high-end setup (eg with SSD fast seeking)>, typical figures should be 200, 100 and 50 milliseconds".

    Similarly, we could be given typical figures for say opening an example solution.

    Obviously (especially given the exotic flora that inhabit the VS ecosystem) this wouldn’t be a contract between MS and customers.  But it would help us to know when VS is working as expected and when something is wrong with our own setup.  

    As an example, using XP64/VS2005 with one AV product, F1 help took almost a full minute to come up on first time use.  This came down to about 15 seconds with an alternative AV.