Visual Studio 2010 Performance Part 3: A Technical Update

If I have any readers left out there, they might be interested to know what it is I’m up to this month.  It’s a very important something.  It’s... my vacation!  Ok, seriously, I am in fact on vacation and I’ll be out for the next few weeks mostly because I’ve been working really hard on VS performance for many months now and I’m kinda tired.  But, you still deserve a brief note from this tired camper, which I’ve been meaning to write for a while but something always came up – sorry about that :) 

So, from my vacation, here’s a quick note. 

This is, more than usual, one of those postings where I wish I could be giving you a lot more detail but you’re just going to have to wait for that next beta for things to be fully revealed.  But I can say a few things, especially about technical issues, without getting into trouble.  Really, if you want to know about what features need(ed) work, the easiest way to guess is to look at what people were complaining about.  It turns out they weren’t imagining things – go figure. 

Technically, we found all sorts of fun issues. For instance, the product is a lot more multi-threaded than previous versions and in some cases synchronization between threads was less than great.  In some cases code designed to defer background work to keep the foreground responsive was actually slowing things down; in two cases I actually took out Sleeps, no joke! In some cases threads where synchronizing when they did not need to do so, destroying effective parallelism.  In other cases latent parallelism designed into the system wasn’t exploited at all, and rounding things out there were cases where there should have been parallelism in the design and it was totally absent.  That’s pretty much the full menu of problems you could have in that space.

In the past, the IDE was just “flirting” with becoming a managed application, for some scenarios you could actually avoid the managed code entirely.  In Visual Studio 2010 you need only look at the profiles and observe how much time we spend in clr.dll to see that at this point Visual Studio is dominantly managed.  That brings a lot of benefits but also potential problems.  In many cases our first cut at communication between the managed and unmanaged pieces was pretty much terrible – all kinds of redundant copying of data, predominantly text, resulted in a lot of wasted CPU cycles and memory.  Many internal interfaces were redesigned to better cooperate between layers.  COM interop cases sometimes made this even trickier with CCW/RCW objects being created destroyed far too aggressively.  In some cases moving a nicer chunk of the work to the managed side helped a lot – kind of like writing stored procs for your database – good procedures mean fewer round trips and less data to move.

Recently, we started taking a hard look at overall consumption and a lot of improvements are coming out of that work.  Memory is of course the main issue and there are three main sources of bad consumption that are getting targeted:

1. Managed images, especially ngen’d images.  It’s just super, super, simple to take a dependency on a whole DLL in the managed world when all you need is a tiny slice of it.  This has the lovely property that others then build on those DLLs creating a great big tree of unneededness.  The good news is that examination can often lead to good refactoring opportunities which can save everyone a lot of memory.  This is for sure the #1 issue.
2. Unshared, unmanaged Heaps.  There are many low level pieces that manage their own memory and they inevitably do it with CreateHeap – joy.  Of course they make their own nice giant heap ready to go and then put about 22 bytes in it.   Multiply that by all the components that think they need their own private heap and it gets unpleasant awfully quick.  Thankfully, this, too, is somewhat addressable.  Interestingly managed memory use hasn't been a big problem other than it's fair share of leaks (see next)
3. Memory leaks, pretty much universally, can be a problem in a product the size of VS.  No technology is immune but I sure like finding the managed ones better than the unmanaged – they literally can’t hide.  Other things that look like leaks but aren’t really – it’s important to use AddMemoryPressure/RemoveMemoryPressure to give the GC a chance to help you with your handle objects.  VS has a lot of those.

I think you’re going to be pleased because we’ve been hitting most of the complaints squarely on the head.  From my chair, the product feels much, much, better.

That’s it for now, I can’t wait to get another build into your hands!

Comments

• Anonymous
  August 19, 2009
  "can be a problem in a produce the size of VS", So I can find VS in the produce department at my local grocery store?

• Anonymous
  August 19, 2009
  Cut me some slack here, I'm on vacation :) Fixing :)

• Anonymous
  August 19, 2009
  Hope you have a relaxing vacation Rico, sounds like you've earned it. It's certainly quite a challenge to be delegated with sorting out the VS2010 performance issues.  Not sure I'd want that job resting on my shoulders! It does sound like you've taken the bull by the horns though, and things are getting under control.  I'm definitely looking forward to seeing the results in Beta 2, along with changes promised in other areas, such as the text rendering improvements. Any idea (just roughly) when Beta 2 is due out?  If you can't tell us directly, a cryptic clue would also be welcome :-)

• Anonymous
  August 19, 2009
  Beta1 was not bad but it looks like Beta2 is going to be much better. Can't wait for it.

• Anonymous
  August 19, 2009
  When the next beta does go out, will you go into more detail about things hinted at in this post?  I would love to read about some specific cases.  The Engineering Windows 7 blog did a good job of going into internal changes, as did the Channel 9 videos about redoing the kernel locks.  I'd love similar posts on VS that dig into the internals and performance and changes that were made.

• Anonymous
  August 19, 2009
  The comment has been removed

• Anonymous
  August 19, 2009
  Thank you Rico for such an open post. One doesn't read every day about the real problems of a commercial produce (oops, product, just kidding). Enjoy your vacation !

• Anonymous
  August 20, 2009
  Regarding #1 - taking a dependency on an entire DLL when you only need a small portion of it. Don't you now wish the CLR would have had a linker? Curios what's your take on this.

• Anonymous
  August 20, 2009
  Interesting posting Rico. As ever I really value your pragmatism and honesty about the development process. Like everyone else here I can't wait for the next beta - really hope it isn't being held back for the PDC :-) Hope you're having an awesome vacation!

• Anonymous
  August 21, 2009
  I suppose some small comfort can be taken from Beta 1 in that Microsoft developers make the same mistakes as the rest of us :) Looking forward to Beta 2. Has the Add References dialog been fixed yet?

• Anonymous
  August 24, 2009
  The comment on the linker was interesting. I am hoping that you could provide more information on the impact to memory.  I can see it slowing load times from disk, but, I am unclear as to the dramatic memory impact.  I see that there are some 3rd party linkers out there: http://www.remotesoft.com/linker/index.html Does using "ilmerge" help? http://research.microsoft.com/en-us/people/mbarnett/ILMerge.aspx