As John mentioned last Wednesday in the preview 5 announcement post, we are investing heavily performance improvements in this release. This is part one of a five-part series covering performance improvements for Visual Studio “15”.

Today, I’ll walk you through a set of investments we made to improve the Visual Studio startup experience in this latest release and specifically cover the following topics:

• Using our new performance center, how you can determine if you are using extensions or tool windows that are impacting experiences such as startup, solution load, or code editing. And of course, how to optimize it.
• How moving extensions out of the startup path using an on-demand-load approach and optimizing and deferring cache initializations help us improve the startup times.

As the Visual Studio user base has grown tremendously over the years, so has the variety of partner technologies used in Visual Studio. Unfortunately, some of the extensions significantly impact Visual Studio startup time as features and extensions load automatically at startup.

Below is an example indicating how Visual Studio startup time could easily get 50% slower when loading extensions at startup.

What is involved in Visual Studio startup?

There are three different Visual Studio startup types:

1. First launch: the very first launch of Visual Studio after setup has finished. First launch of Visual Studio is considerably slower than other startups because the Visual Studio environment is configured with various caches and prebuilt tables.
2. Normal startup: we call subsequent Visual Studio launches, following the first launch, as normal startup; such launches exclude debug instances, or instances launched using command line arguments, as well as instances where an extension or update was installed before. 80% of Visual Studio startups fall into the normal startup category.
3. Configuration change: a startup that occurs after when an extension or update is installed.

These types help us identify the root cause of potential slow-downs and enable further investigations for optimizations.

First launch improvements

In Visual Studio 2015, a first launch startup involves scanning installed components and creating a configuration hive, initializing default settings, getting user sign-in information, and initializing caches such as the Managed Extensibility Framework (MEF), extension manager, toolbox, and font/color caches.

In Visual Studio “15”, we have considered each of these steps to see which ones can be deferred or optimized:

• We experimented with deferring toolbox initialization in Visual Studio 2015 which had a positive impact on load time and changed it permanently in Visual Studio “15”.
• Some caches like the font and color cache are no longer initialized at first launch. Instead, we significantly improved cache configuration allowing us to defer their initialization until a later time without impacting the user experience at first launch.
• By having MEF and the extension manager service be asynchronous, we can now initialize those caches in parallel while sign-in runs.

With all these changes, we are happy to announce that Visual Studio “15” launches up to 3x faster than Visual Studio 2015. Here is a very early read from our telemetry:

Normal startup improvements

A normal startup of Visual Studio, at minimum, involves initializing core services. Every release we continue to monitor these services to ensure core initialization doesn’t get longer. On top of core services, startup can be impacted by two major additions; extensions that are automatically loaded at startup and tool windows that persist in the window layout from a previous instance. Our telemetry suggests that automatically loading extensions, including both Microsoft and 3^rd party ones, significantly increase Visual Studio startup time.

As mentioned above, our primary focus in Visual Studio “15” has been avoiding automatic loading of extensions and providing more options for those extensions to be able to load later without impacting the user experience. As part of that work, we have delivered features like:

• Enabling asynchronous loading support for Visual Studio packages
• Extending metadata rules that control automatic package loading and command visibility
• Supporting asynchronous query of core Visual Studio services

Xamarin and Python tooling are the first to adopt the on-demand-load approach in Visual Studio “15”. You should now see that startup is considerably faster in cases where you have these extensions installed.

Another factor that impacts startup is tool windows that are visible on the IDE at the startup time. These tool windows persist from the previous instance and such tool windows add time depending on the size of the features they initialize; and some of them are quite noticeable. We continue to focus on improving performance of such tool windows based on our telemetry. In addition, the Manage Visual Studio Performance dialog helps you override default persistence behavior for these tool windows going forward. You will learn more about this dialog in the next section.

Monitoring extension and tool window performance

While we are minimizing the need for auto loading features at startup, we also added a feature in Visual Studio “15” to help users understand the impact of their extensions and tool windows at startup and other scenarios such as solution load and editing. Yes, this feature does auto-load to monitor what happens during Visual Studio startup.

When you launch Visual Studio, for a slower extension you will get a one-time notification regarding the extension’s performance impact on startup.

At any time, you can go to Help -> Manage Visual Studio Performance to open the dialog and see which extensions or tool windows are impacting your Visual Studio’s startup, solution load or typing performance. From the Manage Visual Studio Performance dialog, you can disable the extension.

Like extensions, you can see the impact of a tool window in the same dialog. If a tool window slows down the Visual Studio startup significantly, you will also get a notification. You can override the default persistence behavior by choosing from one of the two options below:

• Use default behavior; no change to the current behavior. Hence, you won’t get any benefit if you chose this option.
• Do not show window at startup; tool window will never persist between instances. You can open it later from a menu.
• Auto hide window at startup; if tool window is visible at startup, this selection will collapse its group to avoid initializing the tool window. This option is my favorite.

You can always revert these options by going back to Manage Visual Studio Performance dialog and changing the option to Use default behavior.

Continue to help us

While this post focuses on startup improvements, there are also significant investments in solution load area that my colleague Will Buik will talk about in the next post. Together these changes should allow Visual Studio to start faster when opened with a solution selected from Windows Explorer as well.

You can help us make Visual Studio a better product for you in several ways:

• First, we monitor telemetry from all our releases, including pre-releases. Please download and use Visual Studio “15” Preview 5.
• Secondly, if you are an extension author, stay tuned; in the upcoming weeks, we will post details on how extension authors can analyze their extension. As any extension that chooses to auto load at startup or when a solution is being opened can negatively impact performance of Visual Studio. The coming guidance will help evaluating if new features in Visual Studio “15” can be used to remove the need for auto loading or reduce the impact of auto loading. For those extensions that need to auto load, the guidance will also help with measuring the impact on startup.

Thanks!

Selma

Selma Ikiz, Program Manager, Visual Studio IDE Selma has been working in developer technologies since she joined Microsoft in 2009. Her major focus has been delivering performant and stable IDE to developers. She is currently working on improving the new Visual Studio Installer through telemetry.