Preview of Visual Studio 11: Wither Performance?
Previous articles in our mini-series on the upcoming Visual Studio 11 have discussed new features of the supported programming languages and the IDE. Today we'll take a look at another important aspect that affects all developers using Visual Studio: performance.
While not as exciting as new features, the performance of the Visual Studio environment has been a reoccurring developer concern throughout multiple generations of the product. That concern has continued into the present with Visual Studio 2010 and the recent release of Visual Studio 11 developer preview. Earlier this year Microsoft released the Visual Studio extension PerfWatson specifically to collect real-world performance data from Visual Studio 2010 SP1 users with the goal of correcting these issues before Visual Studio 11's release.
Since then PerfWatson has been integrated into Visual Studio 11 to assist Microsoft's development team in correcting issues that arise as that build takes shape. Microsoft's Larry Sullivan, Director of Engineering, recently provided an update on the performance category of the Visual Studio UserVoice feedback website. Sullivan states that over “4700 posts and votes” have been received and that he wants developers to continue providing comments and PerfWatson data.
Sullivan's update sparked some spirited remarks from users. Reviewing a portion of the comments expresses the frustrations many developers are experiencing:
User Darrell wrote:
“Yes - this is great that you're listening to the feedback for V.Next, but what about V.Now? Can't we get some of those fixes to a SP for VS2010? Visual Studio is seriously driving me a way from Windows development. VS crashes on me 2-3 times per day due to OOM issues (running 64bit with plenty of memory), and I'm constantly having other perf issues that just make my life hell. The way things are going, my next contract will _not_ be doing .NET development, or at least not on Windows anyway.”
User Santosh Kumar Arisetty wrote:
“My Visual studio 2010 gets restarted at least twice in a day. It reports an issue, thankfully. I hope all these issues will be resolved soon to make it much robust. It would be really great if these were made available as a part of SP for VS2010 rather than VS2011”
User PleaseFixYourBugs wrote in part:
“You finish your performance work??! You validate your wins??? Excuse me, but I have yet to see any of that. I spent quite a bit of time playing with the Developer Preview of VS2011, and it is every bit as slow as VS2010. And you say you are wrapping up already?! Outrageous.”
User VS Perf wrote:
“I would think the best way to fix VS performance is to use it on all projects internally, dogfooding. I have gotten the impression some/many of your developers don’t use it internally, especially for larger projects? or am i missinformed?”
These and other comments caused a follow up post from Sullivan. First he wanted to clarify that the Developer Preview role versus that of the scheduled Visual Studio 11 Beta:
“I should have been clearer that we are in the process of shutting down our big push on performance improvements for Beta, not for the release and I do look forward to everyone getting the Beta and feeling the improvements. The Developer Preview was really about showcasing our support for Win8 and Cloud development along with new ALM features and the Team Foundation Service. We did work to plumb the product to gather better telemetry on where you spend time waiting on Visual Studio. This work did not show up as wins in the Developer Preview, but greatly helped us better understand the most problematic areas in Visual Studio and this work will pay dividends in Beta and beyond.”
Addressing user “VS Perf” questions about dogfooding (the practice of using products internally), Sullivan had this to say:
“Dogfooding has been mentioned and I want to let you know that we do dogfood Visual Studio and TFS inside Microsoft. We use our products to build our products and we do this for just the reason you state so that every developer does have a feel for the product. To give you a bit of a feel for scope - we usually have hundreds in the Visual Studio organization working on the latest builds and outside Visual Studio we have a number of partner teams that use builds of the current product for their work as well. The Developer Division uses TFS for all of our source code management, bug and work item tracking so that we use the full scope of our products.”
InfoQ will continue to track Visual Studio 11's development to see how these performance changes manifest themselves in released code.
I hate to say this..
Let's face it, it has just been a dog for years and years, and it wouldn't be surprising to see performance wither away some more in the next version.
This just not good enough!
Microsoft should not use Visual Studio to build Visual Studio just "so that every developer does have a feel for the product" but because Visual Studio makes it more easier, less costly and more fun to build Visual Studio with itself then w/o itself!!!
If developers must use VS just so that they can feel the product, then VS will stay what it is now.
If developers use VS and find ways for it to be more productive, then there is a hope...
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015