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