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!