Visual Studio 2010 Performance Part 1: Startup

I want to start by thanking everyone that has commented on the Beta (by posting their thoughts here or elsewhere) for doing so. Please keep those comments coming! They have a great impact on the senior leadership here and they are excellent rallying points for all the teams. They really do make a difference!

Jason has come right out and said he’s tapped me to work basically full-time on performance work for Visual Studio until we’re done; that’s understating the situation if that’s possible. I think I had already tapped myself before he tapped me and at this point I’m a bit of a lightning rod for performance issues in the product. I think that’s a good thing. 🙂

Just like I did back when I was writing about performance problems for the CLR I’m going to talk about things as candidly as possible. Including the bad parts.  While I do that I want you to keep in mind that I write the truth as I see it and I often have to write what I like to called “approximately correct” articles, mostly in the interest of brevity; being more than approximately correct causes the word count to skyrocket. I won’t keep reminding you that I’m doing this but it’s been a while so I thought maybe a refresher would be good.

Lastly, I try to use affirmative language about what I’m doing or what I think the teams are doing but I generally avoid making promises even when any idiot could see that we would be colossally stupid to do other than what I am discussing or perhaps what one of my readers has suggested. I avoid it because there are many teams involved, with many choices at hand, and many opportunities for things to go badly despite the best laid plans. So I just try not to go there. I’m sorry about that.

OK enough disclaimers already.

This is, what I hope is the first in a series of articles about performance related happenings in Visual Studio. I hope you find them helpful and interesting. I’m going to start at the start – and that’s Visual Studio startup.

I’ve actually talked about Startup several times over the last few years. That’s because I want people to understand that of all the things that are going to get better, startup is not one of them. Yup, that’s right; I gave up at the start. No kidding. No pretending. It’s going to start slower. Sorry.

But wait; don’t give up on me yet!

We decided to make some investments in better display technology in this release and for the future; that meant loading WPF at startup. We decided to have a superior extensibility model for our future and that meant MEF at startup. And in general we went from having no managed code at all at startup to having a LOT of managed code at startup. That stuff isn’t free, and nobody knows it better than me. [I rhymed]

In some cases I’ve seen as much as 75% of our time in current startup scenarios actually in clr.dll – incredible isn’t it? In VS2008 that was 0%! But even though that’s technically true, it’s also a bit of a lie…

In VS2008 you could start the IDE without bringing in the managed stack and you could avoid allocating say the GC heaps and whatnot but it’s an illusion. For the most part, if you did anything real you would find that you had paid that cost very shortly after startup and almost certainly before you were “Ready to Work.” That experience is the one that I wanted teams to focus on in this release: don’t prioritize start to empty, prioritize start to ready.

Now in start to ready we are in much better shape. There were many, what shall I call them, hmm, known weaknesses? There were known weaknesses in the startup path from initial boot, to opening your solution, to opening an editor. I’ve talked about many of these in the past. Consumption in the project system and language systems was high. Editor related algorithms were costly, quadratic complexity or worse in some important cases. That means there is opportunity there. So we keep fighting to create an overall experience that you’ll find better, one that will make you more productive, even though we’re giving ground on some parts of the experience.

Now if you think we’re going to open a small foo.txt file as fast as say notepad… well… I’m sorry, we’re not going to do that. We never had a chance. Other editors are making other kinds of tradeoffs and are much better positioned to give a great experience in that case. But if you want to open say a medium sized solution now we’ve got a fighting chance to offer real advantages.

Now maybe that sounds great, or maybe it doesn’t, but in any case the trouble with focusing on end-to-end productivity is that even if you do make the “on average” experience better you still run the risk of having some painful parts be worse than they used to be and those parts just totally ruin the experience for customers. We’re trying to be mindful of that. Take for instance our friend the Add References Dialog, I don’t think anyone is thinking about how “on average the product is faster” when they are waiting for that thing to come up.  I’m sure not.

So this article is supposed to be about Startup, what are we doing to make it better? Well, there are some very specific things that we think are going to help. These ones represent maybe 25% of the total cost of startup (to empty) in the beta build.

  • We use WPF toolbars and the toolbar layout code in the beta is naïve. That needs to get better (I like what I see so far)
  • WPF does drawing in the background with a render thread; that thread sometimes has to synchronize with the main UI thread. Some of those look like they can be removed.
  • The way we create the toolbars is more complicated than it needs to be. We can get the exact same result using fewer UIElements with some style and code changes
  • We have a hot list of methods in the CLR that are important in our startup, we’re hoping some of those can be improved, and also that those improvements aren’t unique to Visual Studio
  • A classic thing that happens in every Visual Studio release is that we go through a period where we have bunches of code (often VS packages) that are getting loaded at startup that to not need to get loaded at startup. We’re making a list and checking it twice.

The best thing about most of these changes is that they actually help many scenarios (e.g. almost every time we change modes) not just startup.

These things will help Start to Empty to be as good as it can be.  I’m going to talk about Start to Ready more in a later posting.

Comments (31)
  1. Thank you for submitting this cool story – Trackback from DotNetShoutout

  2. Troy says:

    Hello Mr. Mariani, and thanks first and foremost with your honesty. I am not going to lie and say that I enjoy the fact that the RTM startup time will not get much improvement over B1.

    I have been a user of VS sine VS97 and even used VC1! (back when it was all seperated), then briefly moved to Java where Eclipse is the reigning IDE king, and then back to VS.

    When I was doing Java, Eclipse loaded slow like molasses but I didn’t care, no did any devs on my team, and I am going to tell you the reason why:

    Not once I recall the Eclipse IDE even crashing on me, so we would start it at the beginning of the day Monday and not close it until probably Friday evening. So you had to pay only once for the slow startup time and that slight loss was more than made up by the robustness and the usefulness of the IDE (it is just such a beautiful and rich environment).

    Visual Studio on the other hand, I don’t recall a single day where I did not restart it at least twice during the day, and if you let it run for a long time it would get so unstable that you had to close it, so some cleanup and restart it.

    So if the slower startup time is counter  balanced by more robustness and hence less need to restart the app, the impact will be lesser.

    Now that doesn’t mean that it should always be slow.

    Looking at Beta1 splash screen load, I don’t understand half the icons on that screen that I am assuming are language services that are loaded on startup:

    What the heck is the "Microsoft Silverlight Project" or the "F#" or the "Visual Studio Tools For Office"? Why isn’t there a "Startup configuration screen" that allow me to control exactly what gets auto-loaded on start-up so I can disable items I know I will never be using?

    The extension and add-in manager do the right things by allowing you to enable/disable/aut-start add-in and extensions..maybe all these language services should be provided to the VS Core IDE as services as well that you can configure to autostart/manual start/ if I am doing only native win32 C++ I don’t need any of these other items to load when I know in advance I will not be using them in the foreseeable not only am I cutting on load time, I am also cutting on memory usage.

    I know it is not a trivial task…but maybe this should be the direction for the next release.

    Sorry for the long post…I have more to say, but I will leave the chance for others to express their views.

  3. Yannick says:

    << We decided to make some investments in better display technology in this release and for the future; that meant loading WPF at startup >> Did you consider using a more effective technology to handle the display, like for instance Direct2D, before deciding to use WPF?

    I agree with Troy, it would be great to choose which services (languages support, etc.) we want to install / enable before to reduce the memory footprint / disk usage.

    I also think a 100% native version (e.g. with no dependency to .NET) would be very valuable – Native developers do not care about a lot of features added since VS7 for the .NET world (and miss some of them that have been removed). I assume a large part of these new features are implemented in managed code, which makes the IDE slower and slower. VC6 remains in my opinion the best version of Visual Studio so far, VC10 is supposed to be the new 6 but I am quite skpetical….

  4. Stephen A. says:

    Despite what it looks like, raw startup performance is not terribly useful. "Start to ready" is more useful and the most important aspect is the time it takes to load a solution and populate the UI elements with that information.

  5. Keith Patrick says:

    I’m going to second what Troy said; performance tradeoffs aren’t the end of the world as long as there is a net gain, but when the IDE itself is as unstable as it is (and this goes back at least to 2005, which I was crashing daily as recently as a month ago, through at least 2008, which has cost me a couple of days of lost XAML due to inopportune crashes as well just in the last 2 weeks), it’s just not worth it (not to mention many times I can’t tell if the IDE is crashing or just gummed up in one of its "pauses")

    But then, stability issues go further than VS (Internet Explorer is – and has been for years – the most unstable piece of software I’ve used from a major vendor since I ran Windows 3.1, although I also put some of the problems on Adobe in spite of the host’s responsibility to NOT CRASH)

  6. JohnGalt says:

    Startup time doesn’t matter to me so long as doesn’t crash all of the time (regular occurance right now with 2008)

    What does matter to me is the delays in the text editor on large files (> 2000 lines). Yes, these files exist all of the time with Winforms and no they do not require refactoring, they require that the editor is way faster and doesn’t get in the way and block typing while it figures out what to highlight.  If this was fixed, I don’t have a problem with the speed of (except opening and saving large forms in the WinForm designer).

  7. ricom says:

    I’m going to be talking about the editor in later postings.

    I want to reiterate my thanks for these thoughtful comments.  They really do help!

    Thank you!

  8. Zaki mirza says:

    Hello Rico,

    I have been playing around B1 and I have one slight issue (two actually, but interrelated).

    1. I cannot find any options for Multi-monitor support.

    2. So I setup my B1 as usual, solution explorer, Class View, Properties, on the other LCD. Now when I exit VS, the main application window closes pretty fast (like it should) but I can see that the solution explorer window and others stay there for a while. O_o. Any comments?

  9. Randy Ridge says:

    Can we get rid of the stupid splash dialog?  

    Mine (in 2008) reads like a novel with all the plugins I’ve got installed.  I know there’s a switch to disable it, but seriously, do we really need a splash screen?  I’d be seriously pissed if notepad displayed a splash screen every time I opened it to jot something down, etc…

    I have no metrics on splash screen impact on startup but displaying it and querying for plugins and whatnot has to have some minimal impact.  The annoyance factor is probably more significant.

  10. Troy says:

    Randy Ridge: With VS taking over 30 seconds to start, there is little choice but to display the splash screen. How would the user know otherwise if the IDE has actually started loading? (if not, they will hit that icon until they see something)

    And I really doubt that the Splash screen itself is stealing any precious CPU cycles. The performance impact of the removal of the splash is really negligible.

  11. Troy says:

    Randy Ridge: But I do agree with you that the splash screen in VS2010 reads more like a novel than a startup bitmap.

    I have suggested way to get around that in my previous comment post.

    As for the annoyance factor, is it really that bad? just close your eyes when it starts 🙂

  12. Randy Ridge says:

    Troy, seriously?  I clicked the icon, do I really need a splash screen to satiate me while I’m waiting?  What other application does this?  Maybe I open a game or something that plays a bunch of titles and logos, but usually they allow me to skip them.  I get that it may take some time to start the app but either show me some video with lots of cool stuff happening or don’t do anything.  This middle of the road splash dialog crap is stupid.  Magnify it with showing me what I’ve installed are you serious?  I know what I’ve installed.  Give me a window, before I can click on File/New Project or File/Recent Projects/The Project I Want you’ll be done loading.  A splash screen?  For Visual Studio?  Seriously?

  13. Troy says:

    Randy Ridge: " What other application does this?"..funny you should ask 🙂




    -Microsoft Office (Word, Excel, PP)

    -Windows 🙂

    -Adobe Photoshop

    -Adobe Acrobat and most adobe products




    -Sony Vegas, sound forge, …

    -Patchmix DSP

    And a lot more…although the majority of these programs allow you to turn the splash screen off.

    A question to you: since you won’t see anything for a good 30seconds+ if you remove the splash would you know that the program actually started? or maybe you want to see some other bitmap as a splash screen with a progress bar and dynamic elements?

  14. Randy Ridge says:

    Seems like nothing more than a crutch to me, if it takes so long to load the app that I don’t know something is happening then there’s a problem.  My "one-one thousand etc" test shows me that visual studio loads the application window in ~4 seconds on my box cold (though it takes longer to be able to do anything, the splash screen is up almost immediately and only visible for about about two one-thousand).  It’s roughly the same for photoshop.  My point is that this doesn’t do anything useful for me, I can barely read the splash screen before the window comes up, so what’s the point?  Photoshop doesn’t list every single plugin when I launch it, why should VS?  Even better, why have the splash dialog at all?

  15. Anders Borum says:


    just wanted to state that I’m getting exceptional fast load times with VS 2008 SP1 since I switched to a SSD on a Server 2008 x64 install. Loading performance wasn’t really bad previous to the SSD, but now, when I click on the icon on the desktop, it takes less than a second before the IDE is ready.

    Therefore, I’d advocate spending more time on stability (as is mentioned by other users) and making it more enjoyable working in VS (after it’s loaded up).

    It’s all about the hardware. I reckon most serious devs will be using SSDs in the time frame of VS 2010s lifetime.

  16. ShuggyCoUk says:

    Some thoughts:

    I am almost always opening a specific solution when opening Visual Studio.

    Can that scenario not significantly improve the start up time by, for example, not triggering any ASP related code if it doesn’t need it.


    Whilst the MEF is a wonderful thing in most cases the *discovery* process is *not  required every time I open the app*. The number of times this set up changes verses the number of times I open VS is a ratio I would posit at 1:1000 or higher. Have the thing start up assuming the same set up as before and, if this turns out to be wrong [1] redo.

    [1] obviously there are two ways this can happen,

    a) the thing you expected to be there isn’t, fast awareness, simple no user intervention restart yourself with full discovery.

    b) something new is there, you would only be able to spot this via a background post start up thread that did a quick sanity check and either: let the user know that a restart is required to get the new functionality or just make the next restart happen with full discovery.

    If someone is messing about with IDE integration (i.e. writing a plugin) either a command line switch or an option toggle to activate permanent full discovery is a reasonable thing.


    I tend to run multiple instances of VS (normally with different solutions) and that scenario has many issues unrelated to performance (options changes taken from last closed and the like) but in terms of performance I percieve a reasonable speed up in startup of one over the other. Is your VS specific (as opposed to framework specific) managed code going to be n’gened and tweaked for minimal private pages?


    Find References and other refactoring tools are appallingly inefficient. I ask for all references to a private variable and it feels the need to background recompile my entire solution! OK internal is a bit more tricky with InternalsVisibleTo but essentially that feature set is almost never used because I either buy resharper or just use find!

  17. Daniel Rose says:

    For us, editing/typing speed is the major problem with VS.

    Our main solution is relatively large (almost 60 projects, about 34MB source code). It is in C, with a bit of C++. Additionally, there is a bunch of Fortran converted with F2C and Objective-C converted with OCC. Some of the files contain 30k LOC (no, I didn’t write them).

    With this, VS becomes slow as molasses. Typing or even just moving the cursor can sometimes take seconds (this is on a Quad-Core Q9550 with 4GB RAM).

  18. Daniel Rose says:

    Randy Ridge: "Photoshop doesn’t list every single plugin when I launch it."

    On my box at home (about 7 years old), Photoshop takes half a minute or so to start. And its splash screen shows the plugins and DLLs it is loading.

  19. Jalf says:

    @Randy Ridge: The splash screen might not be useful to you, but is it harmful? If not, why not leave it? That way, people who are on slower computers, or have more VS plugins slowing down the load, or whatever else, will be able to see that the app has been started. Why rant and rage so much against a feature that, at best, is completely harmless?

    (Although a quick test showed me that it can be improved a bit. On my laptop, from I click to launch the VS2k10 beta, it takes 8 seconds before the splash screen shows. And then another 3-4 before it disappears again. If the splash screen is only visible during the last 30% of the load process, it suddenly becomes pretty pointless ;))

  20. tobi says:

    is startup perf really that important? i do that once a day because hibernation does not work on my box. if it did i would restart vs once a week.

  21. pingpong says:


    The way we create the toolbars is more complicated than it needs to be. We can get the exact same result using fewer UIElements with some style and code changes


    So it’s possible to create WPF toolbar which has visible impact on the load time of a complex app, like the VS2010 IDE? How many buttons are there, anyway?

  22. zzz says:

    The startup on modern low end desktop (c2d based) is fast enough in Beta 1 on Win7RC. Stepping and compiling performance (c++) are important as those happen quite often vs startup.

  23. Joel says:

    Here’s my biggest performance beef with VS 2008 (and earlier): don’t penalize me for hitting F1. If you can’t start the help viewer instantly, start it on another thread so it doesn’t lock up my editor while I’m waiting for the help to come up.

  24. zzz says:

    Joel that could end up looking like "why isn’t this f1 doing anything" then up pops dozen helps after pressing it few times. There has to be some indication that stuff is happening. Maybe best would be if some of the stuff that the help viewer uses could be loaded on background priority after other stuff is loaded.

  25. ricom says:

    Help is totally reworked in VS2010, it uses your browser exclusively to view content.  You should find it a lot faster.  In the beta there is only online help but that’s just temporary.

    Lab machines showed IDE startup in the 1800ms range.  A savings of even 50ms is signficant (they add up) and it’s easy to use that much time on toolbars given the number that we have.  The new code is a lot better. 🙂

  26. Skip says:

    Help being totally reworked in VS2010 and being a lot faster is a good thing, because I can hardly assume if it were any worse in previous versions that it would be considered shippable.

    My experience with VS2008 and VS2005 usually goes like this:

    I hit F1 completely by mistake, having tried to hit escape to cancel the selection of some text, or something, and slightly missing.   That’s about, oh, 99.9% of the time that I hit F1, because tabbing to a browser, hitting google, typing in the name of what I need help on, searching and choosing the MSDN link that is usually the top return and invariably in the top 5 is way faster.   By probably at least 30 seconds if not much, much more.

    My VS window is now unusable.  VS2005 and VS2008 behave differently here.  2005 will, after some time, pop up a window that says that it’s waiting on an external app, and would I like to keep waiting or switch to that app?   There’s no actual other app to switch to yet, the help system is still loading.   After one or more cycles of waiting, the window finally opens, and I can close it and go back to work.   If I use process explorer or something to kill the loading help app, VS2005 becomes very very unstable, so you should just cut your losses, close it and restart it.

    VS2008 doesn’t seem to have this window, at least I haven’t seen it.  Instead, the text greys out, and the app is marked as ‘not responding’ for quite some time.  Usually on the order of a few minutes.   Mostly, eventually, the help window pops up and you can kill it and get back to work, but not always.   It seems that, especially if you accidently do this fairly quickly after loading a c++ project, you hit some sort of deadlock and it never opens.   I just did that here, accidently, because I was going to time how long it takes, and I didn’t wait long enough.

    I really probably should just remap context sensitive help to something else that I can’t accidently hit, I guess.   Maybe ctrl-alt-shift-F1 or something.

  27. Stephen A says:

    @Skip: same experience here. I only even hit F1 when reaching for Escape (happens more often than you think, especially on a laptop).

    Using a browser to navigate to msdn is invariably faster than waiting for help to load.

  28. Rico Mariani says:

    We will be using the browser to display help exclusively.  And we’ve done work to lighten the web payload as well;  I think it’s now freakin’ fast (TM) 🙂

  29. Part 1 of this series talked about the startup problems we face.&#160; In Part 2, I want to talk about

  30. Tom says:

    >>of all the things that are going to get better, startup is not one of them.<<

    Rico, I can understand what you are getting at, but I think you are underemphasizing the importance of startup time.

    You guys are thinking that a guy comes in at 9am, starts VS, works in it all day, closes it at 5pm and goes home.  Nothing could be further from the truth.

    In reality, there are lots of users like me who work on all sorts of different things throughout the day.  Because of that, I’m probably in and out of Visual Studio literally dozens of times in a day.  And when I am starting Visual Studio, that’s because I need to do some work in it or to look up something quickly, and the last thing I want is a long startup delay, such as what we have right now in VS2010b1.

    Bottom line: I think there will be a lot of users annoyed if startup time is worse compared to VS2008.

  31. Ryan Molden [MSFT] says:


    So it’s possible to create WPF toolbar which has visible impact on the load time of a complex app, like the VS2010 IDE? How many buttons are there, anyway?


    There are a number of things at play here.  First we don’t have a set collection of toolbars in VS as they can be created by packages, DTE, user customizations, etc.  Further, since they can be manipulated after creation via DTE and/or the customize dialog it is non-ideal to programatically create these toolbars and their controls or else the DTE/Customize code would be working directly against the UI itself instead of some underlying set of models.  To that end we rely very heavily on WPF data binding and styles/templates in order to create/visualize our toolbars (and menu).  Further our toolbars aren’t simply a bunch of buttons.  Buttons are by far the most prevelant item on a toolbar but they can also contain Combos, MenuControllers, SplitDropDowns (okay only Multi-Level Undo/Redo fall into this category), Menus and ContextMenus.  This requires a number of styles that are chosen based on the control type we need to visualize.  This involves WPF style lookup, template instantiation, etc..  I think (from talks I have had with others) what Rico is saying here is that having WPF doing this repeatedly for us is wasteful in that it does the ‘heavy lifting’ of template instantiation ‘the same’ for every button (or combo, etc..)  If we were to follow WPF’s route of specialized types, like ButtonChrome, that transitions the visual aspect of the controls into code-behind, we would likely see speed ups in creation/rendering time as we could optimize the templates/rendering code to be specialized, which will (almost) always be faster than the very  generic way WPF goes about doing these things.  Does that make sense?

Comments are closed.

Skip to main content