The official source of product insight from the Visual Studio Engineering Team
As mentioned in the previous performance post on Typing and Editing we would follow with a post on the improvements to Visual Studio 2012 from enhancements in the Toolbox. I would like to introduce Duke Kamstra and Chuck England from two teams in Visual Studio to describe to you the work done to improve responsiveness via the Toolbox.
Visual Studio is packed with awesome rapid application development features. Sometimes getting all of these great features comes at a price. Producing Intellisense, red squiggles, smart rename, refactoring, etc. can require quite a bit of work. As features have become more versatile, and solutions have grown in size and complexity, we’ve seen that the additional workload can cause the UI to become slow to respond, repaint, or even hang. In Visual Studio 2012, we wanted to improve this experience. In today’s blog post, we will discuss one of the features, the toolbox, and the performance enhancements we have made.
In previous blog posts on performance we mentioned PerfWaston. The Toolbox is one of the features that generated a lot of hits. Armed with this data we designed several test scenarios. We profiled these scenarios using solutions provided by customers as well as ones we created to simulate large, complex solutions.
We learned several things analyzing the performance traces:
To help explain what we changed to improve toolbox performance, it may help to first describe how the toolbox works. At a high-level, the toolbox works in conjunction with a designer to filter the list of all known visual components to a list that is contextually relevant for the loaded designer. So, for example, if you are working in the Windows Forms designer, you see Windows Forms controls, and when working in the WPF designer, you see WPF controls.
The list is built from two distinct types of visual components. First, there are the items that are registered on the machine. These are items that are supplied with Visual Studio out of the box or installed by the user from a 3rd party vendor. The toolbox builds a cached list of these components and makes that list available to the designer. The designer then filters them as appropriate for its needs.
Second, there are user components that are defined in user projects. These are the custom components like user controls, datasets, etc. that you define. For these components, the designer itself is responsible for searching through the built solution’s output and adding them to the toolbox.
The big distinction between these two types is that the registered components are static and seldom change, whereas user components may change often as you update the code in your solution.
For user components, the basic discovery process consists of iterating through all of the build outputs for the solution to locate potential controls that are available for use in the designers. This is performed through a reflection-like process to find the controls. We learned through our performance traces that this “discovery” of user controls is proportionately expensive to the size and complexity of your solution.
While the general mechanism of updating the list of user components was common across most of the designers in the product, each designer had to be specifically investigated to understand the opportunities to improve performance. While there are many designers in the product (e.g. Workflow, UML modeling, DSL (Domain Specific Languages), WCF, DataSet), most are based on one of three common base implementations (WinForms, WebForms, and WPF/XAML). For each of these base implementations, we saw that the largest performance opportunities existed when a user was performing one of the following operations:
To improve the performance in these scenarios, we followed a few basic principles.
The first principle we followed was to stop doing work we did not have to do. It seems to go without saying, but life is rarely that simple. Just because you have established a simple and viable design at one point in time does not mean it will stay that way. This is where performance tuning is required.
One such case for the toolbox is the choice on when the work is performed. If you have a designer open and you have the Toolbox open, then we presume you want to interact with the Toolbox and the design surface. So, we make sure that all the visual components in the toolbox are up to date and relevant.
But what if you never open a designer? What if you have a designer open, but the toolbox window itself is closed? In these cases, we found that we were still making sure that the toolbox stayed up to date. As a result of our tuning work, we have eliminated this work until we see that you have an open designer and the Toolbox is visible.
Another tuning opportunity was found in designers’ code that ensured the toolbox is always up to date. After a designer searches for new or changed visual components, the toolbox window is updated with the results. In Visual Studio 2010, several designers accomplished this by removing everything and then adding all of the newly discovered items in bulk. In many cases, the items may not have changed much if at all. Our analysis showed this to be very inefficient, requiring considerable work and UI repainting. To improve, we only add or remove visual components from the Toolbox that have changed since the last update.
A second principle we applied was to remove work from the UI thread. When long running work occurs on the UI thread, Visual Studio can’t respond to messages from the operating system to repaint the window or to process user input such as mouse clicks or typing. In contrast work that occurs asynchronously on a background thread does not prevent the UI thread from processing messages. This is how we ensure a responsive UI.
The performance traces identified several cases where work for toolbox was being performed on the UI thread. One example was the work that is performed by designers to discover the custom components in the solution.
After we applied these principles, we compared the before and after of some common scenarios with the toolbox and a designer open. The chart below shows the performance gains that we made based on all of the tuning and targeted performance changes that we made over the course of Visual Studio 2012. (Yes, these are % gains over previous times.)
Note that these numbers are against a set of internal benchmark solutions. Different solutions may see different results. The typical margin of error for these test cases is +/-5%.
Load Solution with Toolbox and Designer Open
Load Solution with Toolbox Open
Open Designer with Toolbox Open
Change Build Configuration with Toolbox Open
Rebuild with Toolbox Open
Incremental build with Toolbox Open
Close Solution with Toolbox Open
Remember the ~30 seconds of unresponsiveness I mentioned when closing a large solution in Visual Studio 2010 SP1? Our tuning reduced this time in our test case down to ~700ms.
But the numbers are only part of the story. To see the impact, you really have to see it for yourself. You can pick up the latest pre-release version of Visual Studio 2012 here. For those of you who have tried the RC, feel free share your impressions on its overall performance in the comments section, on our UserVoice Site, or you can report new issues to us using the Visual Studio 11 Feedback Tool. If you regularly work with a large number of custom components, in Visual Studio 2012 you will find that it is now much more responsive and you can almost immediately get to work.
Chuck England – Program Manager, Visual Studio
Short Bio: Chuck England is a Program Manager who currently works on core architectural and performance related improvements in Visual Studio. He previously worked to help deliver the Project System and MSBuild which shipped in Visual Studio 2010 / .NET 4.0 and now in the upcoming Visual Studio 2012 / .NET 4.5 releases. Chuck has an extensive history in development with a little over 30 years as an architect and developer in various software industries prior to joining Microsoft in 2008.
Duke Kamstra – Senior Program Manager, Visual Studio
Short Bio: Duke has been at Microsoft 8 years, working on various parts of Visual Studio for the last 5 years. His current role is driving performance improvements across the Visual Studio product line.
We hope these and the other improvements we’ve made Visual Studio 2012 RC are providing you additional productivity gains and making your development experience a great one. Please help us continue to improve through your feedback and suggestions! I greatly appreciate you taking the time to read and comment on these posts and as always I appreciate your continued support of Visual Studio.
Director of Engineering
Hi ! I use the visual Studio 2012. and it's new features like Creating and Consuming LightSwitch OData Services,Enhance Your LightSwitch Applications with OData, Using LightSwitch OData Services in a Windows 8 Metro Style Application are Amazing. Thanks For Sharing.
Too late, that thing was so slow that the first thing I do after installing VS.NET is close the Toolbox and open it only when needed and avoid it when possible.
Microsoft always say they improved this and that, my expectation is when we start using the final VS.NET 2012 the toolbox will be much faster, instead of half an hour, it will take now just 11 minutes :-)
Glad to see that Microsoft is using good design principles to improve performance. Please continue to work on improving performance.
I agree with many others, I can't believe it took almost 10 years to resolve this "issue" with the slow responsiveness of the toolbox. Thanks for the many improvements!
I saw, though, that time actually increased for WPF/XAML--as if that wasn't slow enough already in VS2008 and VS2010. I'm with one other commenter, I always "code" my XAML, as the GUI editor is just way too slow. I suggest your team spending a lot more time on improving the responsiveness of WPF development (especially if it truly is replacing WinForms, as it seems to be with Win8).
VS2010 theme option??
I hope Visual Studio 2012 RTM will compatible to windows vista and xp users.
ABSplash is a small group of people who tries to develop new applications and design new software for your daily use.
We bought our own domains absplash.com and absplash.net, we have full copyright with them, plus they are 90% done but we still need more people with us to finish our work faster.
We need some programmers, graphic designer, social organizers and website editors. the paycheck will be each two weeks, and every member will get equal money from 50%, so if we gained $1000 in two weeks then $500 goes to me, and the other $500 will be split on member's,
What we require you to know,
Programmer: ( VB.NET , C++ ) Python and Java are optional.
Graphic Designer: ( Photoshop , Blender ) Sony vigas optional.
Social Organizer: ( Twitter , FaceBook, YouTube, ABSplash blog ).
Every member should be active at least 5 hours per week, and you get more paycheck if you were more active.
To Apply, contact firstname.lastname@example.org with the following details:
Full Name, Age ( 14+ ), Social apps ( skype, msn, google talk, yahoo ) atleast 1, job , country, preview of your works.
Please.. for the love of God.. don't ship it with this UI or at least allow us to skin it. ALL CAPS for menu items? ARE YOU KIDDING ME!!! the drab and dull UI is abysmal. It almost makes me want to NOT move from vs 2012 regardless of performance. Who came up with this design? Worse yet... who's the person that actually accepted the pitch that a UI which looks like it was made for an app in the early 90's was something exceptional?
This flat and dull "metro" style is going to fall flat on its dull face.
The Loading process of vs2012 is much faster than vs2012. But there much more and new bugs in VS2012 (windows forms) + designer + DataAdapter config.. I'm working with vs2012 since two weeks and it's going slower every day.
I haven't notice improvements in Visual Studio 2012, if anything it freezes all to often and has to be killed and restarted. As I type this it's off in la la land and I'm waiting for it to come back after I made a simple change in xaml code. It doesn't take advantage of my 6 core CPU so it rarely goes over 20% utilization while I'm waiting for it to complete tasks. Frustrating. I'm tempted to go back to 2010 because that one doesn't lock up on me. Time to go kill it again so I can get back to work.