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