Visual Studio 2010 Performance Part 1: Startup

Visual Studio 2010 Performance Part 1: Startup - Rico Mariani

DotNetShoutout — Sun, 31 May 2009 19:44:34 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: Visual Studio 2010 Performance Part 1: Startup

Troy — Mon, 01 Jun 2009 03:53:49 GMT

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/disable..so 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 future..so 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.

re: Visual Studio 2010 Performance Part 1: Startup

Yannick — Mon, 01 Jun 2009 05:26:10 GMT

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

re: Visual Studio 2010 Performance Part 1: Startup

Stephen A. — Mon, 01 Jun 2009 13:42:03 GMT

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.

re: Visual Studio 2010 Performance Part 1: Startup

Keith Patrick — Mon, 01 Jun 2009 17:54:24 GMT

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)

re: Visual Studio 2010 Performance Part 1: Startup

JohnGalt — Mon, 01 Jun 2009 19:26:00 GMT

Startup time doesn't matter to me so long as VS.net doesn't crash all of the time (regular occurance right now with Vs.net 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 VS.net (except opening and saving large forms in the WinForm designer).

re: Visual Studio 2010 Performance Part 1: Startup

ricom — Mon, 01 Jun 2009 20:05:48 GMT

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!

re: Visual Studio 2010 Performance Part 1: Startup

Zaki mirza — Tue, 02 Jun 2009 13:37:12 GMT

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?

re: Visual Studio 2010 Performance Part 1: Startup

Randy Ridge — Wed, 03 Jun 2009 02:48:20 GMT

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.

re: Visual Studio 2010 Performance Part 1: Startup

Troy — Wed, 03 Jun 2009 04:11:03 GMT

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.

re: Visual Studio 2010 Performance Part 1: Startup

Troy — Wed, 03 Jun 2009 04:13:56 GMT

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

re: Visual Studio 2010 Performance Part 1: Startup

Randy Ridge — Wed, 03 Jun 2009 04:45:45 GMT

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?

re: Visual Studio 2010 Performance Part 1: Startup

Troy — Wed, 03 Jun 2009 06:26:25 GMT

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

-Eclipse

-Netbeans

-Delphi

-Microsoft Office (Word, Excel, PP)

-Windows :)

-Adobe Photoshop

-Adobe Acrobat and most adobe products

-3DStdioMax

-Reaper

-Cubase/Nuendo

-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 screen..how 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?

re: Visual Studio 2010 Performance Part 1: Startup

Randy Ridge — Wed, 03 Jun 2009 06:52:52 GMT

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?

SSD anyone?

Anders Borum — Wed, 03 Jun 2009 10:51:29 GMT

Hi,

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.

re: Visual Studio 2010 Performance Part 1: Startup

ShuggyCoUk — Wed, 03 Jun 2009 12:00:52 GMT

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.

Secondly:

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.

Thirdly:

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?

Fourthly:

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!

re: Visual Studio 2010 Performance Part 1: Startup

Daniel Rose — Wed, 03 Jun 2009 12:03:16 GMT

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

re: Randy Ridge

Daniel Rose — Wed, 03 Jun 2009 13:12:37 GMT

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.

re: Visual Studio 2010 Performance Part 1: Startup

Jalf — Wed, 03 Jun 2009 13:17:16 GMT

@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 ;))

re: Visual Studio 2010 Performance Part 1: Startup

tobi — Wed, 03 Jun 2009 14:28:38 GMT

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.

re: Visual Studio 2010 Performance Part 1: Startup

pingpong — Wed, 03 Jun 2009 16:16:36 GMT

[quote]

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

[/quote]

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?

re: Visual Studio 2010 Performance Part 1: Startup

zzz — Wed, 03 Jun 2009 18:42:06 GMT

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.

re: Visual Studio 2010 Performance Part 1: Startup

Joel — Wed, 03 Jun 2009 18:47:54 GMT

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.

re: Visual Studio 2010 Performance Part 1: Startup

zzz — Wed, 03 Jun 2009 18:54:01 GMT

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.

re: Visual Studio 2010 Performance Part 1: Startup

ricom — Wed, 03 Jun 2009 22:17:28 GMT

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

re: Visual Studio 2010 Performance Part 1: Startup

Skip — Thu, 04 Jun 2009 03:26:40 GMT

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.

re: Visual Studio 2010 Performance Part 1: Startup

Stephen A — Thu, 04 Jun 2009 17:50:30 GMT

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

re: Visual Studio 2010 Performance Part 1: Startup

Rico Mariani — Fri, 05 Jun 2009 23:13:48 GMT

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

Visual Studio 2010 Performance: Part 2 Text Editor

Rico Mariani's Performance Tidbits — Sat, 06 Jun 2009 06:04:07 GMT

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

re: Visual Studio 2010 Performance Part 1: Startup

Tom — Sun, 14 Jun 2009 18:02:51 GMT

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

re: Visual Studio 2010 Performance Part 1: Startup

Ryan Molden [MSFT] — Mon, 29 Jun 2009 00:37:30 GMT

[Quote]

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?

[/Quote]

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?