Visual Studio vNext Performance Enhancements

Continuing on our odyssey of exploring the features in vNext, I thought we would look at some of the performance enhancements that have been publicly announced.  Naturally, at this time, I can’t go very deep into the inner-workings of the improvements but will endeavor to list them out and explain somewhat based on information currently available.  Also, be aware that this is a very early look at these features so there will be many improvements made as the product gets closer to RTM.  I’m actually running two versions of vNext currently; the one that will be made available to the public as a pre-release at some point and the one we build internally so I have a pretty good handle on what you will see and what is coming out.  I can say that there are some great things that are being done with the product you will definitely enjoy.  With that said let’s take a look at some of the things we have revealed so far…

 

Microsoft Visual Studio IDE Futures

First off, if you haven’t seen it yet, most everything I mention comes from the great TechEd session done by Weston Hutchins that can be found here:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV326

 

 

Performance: The Four Pillars

For vNext we are focused on four areas of investment to improve the product:

1. Overall Responsiveness
2. Long Running Operations
3. Memory Utilization
4. Better Feedback

 

Overall Responsiveness

As I review the areas of improvement expect a great deal of overlap as many of the improvements fall into multiple categories.  With that said, this area is pretty self-explanatory:  We want vNext to enable users to quickly go about their work without waiting on the IDE.  These improvements manifest themselves in a variety of ways but all have the singular goal of making the product more responsive.  Below are some of the areas that address this goal that we have made public so far.

 

Faster, Stronger, Better Add Reference Dialog

One of the IDE enhancements revealed so far is Add Reference dialog box.  First and foremost it has been supercharged to load almost instantaneously.  How?  We index the assemblies beforehand to have a ready-made list on demand.  We haven’t gone into detail yet on what exactly is being done but expect that revelation in due course.  Also, as with most of the IDE, we have added the ability to search/filter the list so you don’t spend a billion years looking for the assembly you want.

 

Out-of-Process Operations

We have moved some activities out-of-process to give control back to the IDE quickly.  See Memory Utilization.

 

Parallel Operations

vNext will take advantage of multi-core systems much better than VS2010 which will result in more overall responsiveness.  See Long Running Operations.

 

 

Long Running Operations

Building and debugging are examples of a long-running operations that we are addressing.  For example, Visual Studio 2010, while a great improvement over previous versions, really doesn’t take full advantage of multi-processor machines.  Our goal is to speed things up so you can get your work done faster with less time spent waiting.

 

Background Builds

Build operations have now been moved to background threads so you can actually do other things in Visual Studio while a build is happening.

 

Parallel Project Builds

Another great new feature is the ability to build projects in parallel.  vNext comes with an option to have parallel project builds based on the number of cores your system has.  In fact, the default value is automatically set to the max cores on your system.  You can reduce this value if you want.

 

 

Memory Utilization

Responsiveness also includes the overall efficiency of Visual Studio.  We are working on reducing the memory utilization overall based on usage. 

 

Virtual Memory Utilization

vNext uses much less virtual memory internally.  Much of this is due to running builds out-of-process (see below) as well as other enhancements we have made that haven’t been released yet.

 

Out-Of-Process Builds (C++, C#)

C++ has had this feature for a while and we are now brining it to C# and, in a future release sometime after vNext, VB as well.  We now perform builds outside the Visual Studio process.  Instead of loading numerous referenced assemblies inside the VS process they are now loaded into an external process then discarded when we are done.  This results in significantly less memory usage inside Visual Studio which results in a more responsive, stable product.

 

 

Better Feedback

This one is really simple.  How do we get the best information possible when there are issues with the product so we can continuously improve it for you?  Solving for this question is never easy but we have devised ways of obtaining performance data from your actual use of the product to help strengthen our knowledge of areas that need to be addressed.

 

PerfWatson, PerfWatson, PerWatson

The number one tool you can download TODAY to give us feedback on VS2010 and vNext is PerfWatson.  You can get it from the Visual Studio Gallery here:

https://visualstudiogallery.msdn.microsoft.com/fa85b17d-3df2-49b1-bee6-71527ffef441

This tool allows us to get up-to-date, immediate information on the issues that are impacting performance.  This tool is currently built into the pre-release version of vNext and, I suspect, we will include it in the RTM version as well with an option for you to turn it off if you don’t want it.

 

Visual Studio Feedback on Connect

If you haven’t gone to https://connect.microsoft.com/VisualStudio/ yet then you need to.  This is one of the main ways we have been getting directed feedback from you for some time now.  It’s a great way to get to see what others are saying and to communicate directly with the VS team.

Comments

• Anonymous
  September 05, 2011
  The comment has been removed

• Anonymous
  September 05, 2011
  Hey Leo :) I haven't dug into the details yet so take this answer for what it's worth until I can (a) get more details and (b) make sure they can be shared with the public.  Taking your questions one at a time here we go: Yes we could, and have until now, load the assemblies inside VS during builds but it resulted in more virtual memory usage and, for large builds, could make VS unstable with too much virtual memory usage.  Remember this is only for builds we are addressing this issue. Isolating the build process is, I believe, the goal.  I can see adding a marginal amount of time crossing process boundaries but doing this reduces the amount of virtual memory used by the VS process although it may (I haven't done the analysis) increase the overall amount of physical memory used by the system a bit. I'm not aware of any problem releasing assemblies it has loaded rather the problem lies in the amount of assemblies loaded during builds and, in particular, large builds where many assemblies are loaded for the purposes of the build but are then released once the build is completed.  The issue isn't the ability to release the memory the issue addressed is avoiding spikes in virtual memory usage during builds. These are just some of my inital thoughts for now.  I'll do a deeper analysis once the product gets a little further along... Z

• Anonymous
  September 05, 2011
  Great! I'am specifically looking for vNext to incorporate new features from newest accepted C++ standard like "variadic templates" and "constexpr".

• Anonymous
  September 05, 2011
  Hey Dmitry :) I know the C++ team has been working hard to get some great new features in the next release.  Not sure about the particuar ones you mentioned but stay tuned for updates. Z

• Anonymous
  September 05, 2011
  Hi, sounds great, always nice to hear of improvements. When approximately should a pre-release (CTP?) be available? is there any forecast on that? 2012?

• Anonymous
  September 06, 2011
  Lior :) Unfortunately I can't reveal the date of CTP availability but as soon as it comes out I will be posting my series on some of the cooler new features as well as digging into areas that are of interest to you all as quesitons come up. Z

• Anonymous
  September 06, 2011
  looks like a VS2010R2 from what I see. Hopefully the product will be cheaper because it is more like a VS2010 Sp2 instead of a new version.

• Anonymous
  September 06, 2011
  I hope you guys can work with the Resharper guys and get any APIs they use which are not properly performant up to speed.  VS 2010 + R# + WPF is almost intolerable from a performance perspective.  I have taken to keeping my ipad next to the computer for those so so many long pauses that just keep coming up over and over.

• Anonymous
  September 06, 2011
  @Lior: I guess the CTP will be released very soon since Zain implied that the actual 'build' has already been 'built', right ? and there is a rumour said the CTP is built one month ago ..... :P

• Anonymous
  September 08, 2011
  @Andre -- as we are able to talk about the new features I think you will see that the new version is quite impressive. @blorq -- Not sure about R# integration stuff but am sure the JetBrains folks are on top of it. Z

• Anonymous
  September 08, 2011
  @blorq: the performance problem of Resharper has little to do with VS, you can try the standalone product DotPeek of JetBrains, it takes tens of seconds to startup.

• Anonymous
  September 11, 2011
  "Yes we could, and have until now, load the assemblies inside VS during builds but it resulted in more virtual memory usage and, for large builds, could make VS unstable with too much virtual memory usage." Thanks, that make sense. (If they are all still 32-bit processes then huge builds might hit 32-bit addressing limits if everything is kept within the same process, even though on a 64-bit machine you might have plenty of memory to spare. Splitting them up gives you more overhead without having to convert to 64-bit processes.)

• Anonymous
  September 12, 2011
  @Zain - sorry if this is off-topic, but is there anything in VS2010 or vNext that will help VS users identify resource (CPU, memory) consumption or blocking the UI thread on a per-extension or per-addin basis?   For instance, sometimes for a given developer on my team, VS will 'freeze' for a few seconds, or VS as a process will take lots of memory.  At the moment, we're left doing something akin to a bisection search to find the 'offender' (unfortunately not actual bisection since we don't know there to be a single offender causing the issue), but since there's typically not a specific set of UI actions to consistently reproduce the issue, they end up having to spend a few days on each combination to figure out if that particular combination is 'good' or not. We even thought about running VS under CLRProfiler (for memory analysis) or a 'regular' profiler, but the resulting perf and productivity hit (even when lowering the frequency of CPU sampling, for instance) makes it more trouble than it's worth. PerfWatson seems like a good first pass at the issue, but it doesn't seem to make the data available to the end user (AFAICT)? The IE9 experience for start-up seems to be close, where it can tell me that (for instance) the LastPass add-in is causing my start-up to take a full second longer than it would otherwise, asking me if I want to disable it.  Unfortunately, in the VS case, the start-up time isn't really the issue, it's the ongoing usage, making it a bit more difficult to diagnose so far. Thanks!