Performance of the C# editor

Beta 2 & go-live

I hope you have had a chance to download Visual Studio 2005 Beta 2 ("Whidbey").  We worked very hard to get the quality of the Beta up, with the intent that you could use it to build real production applications that you deploy to your customers.  We call this "go-live".

If you choose to do this (I hope you do!), you are likely to begin by porting your existing project to Whidbey.  You may decide to modify your code to take advantage of generics and iterators, or to update your build process to use MSBuild.

go-live and feedback

As you start to use Whidbey to do real work, you are likely to have feedback about things you didn't notice when you were just experimenting with Beta 1 or a Community Tech Preview.  That's one of our goals behind go-live: to get better feedback from real-world usage.

One type of feedback that is particularly hard to get without go-live is on performance.  It's common for folks to use smaller experimental projects on Beta 1, or to install it in a VPC or second PC.  Until you are using your real project on your real machine, and doing real work, it's hard to know if the performance is good for you.

So, please send us your feedback on all of your VS experiences, especially performance.

What we're measuring for C# editor

For C#, we are focusing our performance testing on a handful of key scenarios:

Load solution

Load a medium-sized solution for the first time.  We stop measuring when you can open files from solution explorer & edit them.  Intellisense won't be correct yet, as we still need to parse all the files & build up the type tree.

Wait for C# background load

Load a medium-sized solution for the first time and wait for the C# background load to complete.  The computer should be responsive while this is going, but Intellisense won't be 100% correct until it's done.

Shutdown with solution

Shut down the IDE with a medium-sized solution. 

Scroll

Time to navigate to the end of a file using the DOWN key.  This is primarily a measure of the performance of the colorizer.

Edit

Time to type a file. 

Rename

Time to invoke and apply Rename refactoring across mutliple projects.

Here's some info about the size of the solution that we're testing with. 

Your feedback on performance

With the exception of Rename across multiple projects, we don't intend to do any work to improve the perf sceanrios I listed.  That is, the performance of Beta 2 is the performance we intend to ship the final VS2005 with.  If you think that the current performance in any of these scenarios is unacceptable, we need that feedback.

We don't have any plans to add formal testing of any additional C# editor perf scenarios.  If you find something that's slow but not covered here, we need that feedback, too.  (We test lots of other langauges, debugging, help, etc., etc., but this is it for C# editing.)

As always, the best place to give us your feedback is the MSDN Product Feedback Center ("ladybug").