I need are white suspenders and a codpiece and my costume will be complete.  All in all a surprisingly effective day.  Tomorrow i get to go back to work and work on the final touches for C# before beta2 ships.

Right now we've raised the bar so high that basically all we're fixing are crashes, hangs and any areas that are broken badly (although even those are tough to justify sometimes).  Those are the things we're fixing per se, but now that the product is so stabilized and the codebase isn't churning anymore we've also moved our eyes onto performance.  We've been trying to come up with our scenarios and have been hammering away at the known issues that currently exist (i mentioned a couple of posts ago). 

One of the most interesting things that I've currently had to deal with when it comes to testing and improving perf is the concept of the "minimum requirements".  I don't know about you, but I always thought the minimum requirements were a joke and you wouldn't actually ever run a product on them.   But not here.  The performance scenarios are defined in terms of the minimum requirements and the information from the market has told us that a fair amount of our customers have those types of machines and so they must be supported if we expect adoption.  So what's the minimum requirements for VS?  A Pentium3 600MHz with 128MB ram.  Yikes!

If you're one of those developers out there using one of these machines, then all I can say is... get yourself some more RAM!!!  

How do you do it?  WinXP itself takes up that much just to load, and anything on top of that causes nothing but swapping.  You could be using Win2k, but that's going to be using 64MB all on its own and VS is going to be very cramped.  It's especially tough to conceive given that an extra 128 MB of good RAM can be gotten for ~$25.  But, unfortunately, that's what we have to make VS run acceptably on.

I'm pretty lucky, i get to develop on a sweet dual 3GHz with 2 GB ram.  It's very handy since I'm pretty much always in a continual edit/compile/link/debug cycle, with the latter 3 parts chewing up lots of CPU.  But it makes writing software that requires lots of CPU too easy to do.  I write something up, then load it into C# running on this same box.  Hey, lo and behold, it runs fast enough.  

But, alas dear readers, a little while later we get a frustrated email from some early adopter (or a team of early adopters) talking about how they can't get any work done because VS is sitting there chewing up their entire CPU (Don Box is notorious for this :-) ).  Now, when we get one of these emails I consider us pretty lucky.  This is someone who could have thrown up their hands in frustration, and just downgraded to a previous version, but instead they took the time to report it (which means that now we know about it and can do something about it before it ships to the world).  And so we treat them very seriously and try to fix up the issue as soon as possible.  The consequences of not doing that is ending up with a peeved internal adopter who won't try out new builds and won't send us useful info in the future, and then ending up with a product receiving the complaints we often here about VS2k3.

At that point i'll usually work out getting a repro that I can work on on my own machine, or being given access to the machine where it's happening so I can investigate and determine what the issue is.  After that we'll work hard to find or create a workaround.  Often times a performance issue is caused by work done automatically on idle (like our compiler analysis) and we've tried to make pretty much all automatic idle tasks things that can be shut off through the use of a specific registry keys.  This might break functionality (say like the generate method stub smart tag) but if it unblocks the user and allows them to do work, then it's acceptable.  Unfortunately, if there is no workaround then we try to create a fix and also build a specialized "private" drop to give to them and to any others that might run into this in the future.

Now I know that most of you probably won't be using the first beta of VS2k5 to use in production environments, so we didn't really expect to get any perf reports from that.  However, the second beta is being released with a live license.  This means that you can use it for productions systems and are allowed to create and ship software created with it.  So if you do start using it heavily and notice any performance issues then please let us know!  I really want you guys to love the product and to use it happily day in and day out, and if you're sitting their cursing it because all you do is sit there unable to work then I'm not doing my job :-(