Performance was a big focus area for Visual Studio 2017, with improvements in many areas, including:

• Faster installation
• Faster first launch after installing and faster subsequent startups.
• Faster solution load times for both C++ and C#
• Faster Git operations including fetching the latest version and viewing history
• Faster “F5” to start debugging your applications

There are also some notable improvements in terms of memory usage in key scenarios, which should significantly reduce out of memory crashes (you can now open very large solutions; solutions that were simply impossible to open in previous versions). And Visual Studio 2017 has better identification of extensions or tool windows that may be slowing down key scenarios like startup, solution load and typing.

Start your coding faster with faster startup and solution load

Right after installation, you will notice that it is now significantly faster to launch Visual Studio 2017 for the first time. Most users should find that it is now up to 3 times faster to start working with Visual Studio after installation compared to Visual Studio 2015.

Granted, this is a one-time thing for most customers, so we’ve also made significant improvements elsewhere.

We also made several improvements across different components to ensure subsequent startups are faster by reducing what’s loaded at startup. Some major examples include optimization of Xamarin and Python tooling components to only load when relevant projects are opened. We also added a new feature to help you understand which extensions and tool windows are impacting startup and solution load to give your better control of your Visual Studio environment. We have more details about this below.

You will continue to see improvements as you load your solution to start coding in Visual Studio 2017. We have two new features that will allow you to load your complete solution significantly faster compared to previous versions.

• For C++ based projects, Visual Studio now utilizes a SQLite database to cache information to help open projects faster on all subsequent loads after the first. At the same time, there are improvements in project load time in cases where the cache is not present. These improvements allow Visual Studio 2017 to load LLVM solution 4 times faster compared to Visual Studio 2015 when you use “vcxproj” projects. You can read more about these improvements on the Visual C++ Team’s blog.
• For other projects, we took a new approach to solutions in Visual Studio. We started with the question “Can we support the most commonly used features without actually loading the entire solution?” The result is a feature called “Lightweight Solution Load.” It defers loading of projects as much as possible while still providing the most commonly used features without projects being loaded. For example, using “Lightweight Solution Load”, Roslyn’s compiler solution from GitHub loads 3 times faster now.

Work better with Git source control

There have been significant improvements in the Git source control provider. Most of these improvements are the result of an architectural change in the Git provider to utilize Git.exe instead of the libGit2 library which provided both performance and memory benefits. You can immediately notice these improvements when cloning a Git repo; for example, it is now 3 times faster to clone the Roslyn repo from GitHub.

In addition to making many source control operations faster, we wanted to make sure to highlight one more scenario that was a top user issue before: switching branches for projects under source control. In Visual Studio 2017, you will notice that responding to branch and source file changes is a lot faster because we offer the option to reload the entire solution instead of reloading individual projects. Previously unload and reloading of individual projects one by one could have resulted in unnecessary work as each project reload resulted in an expensive dependency calculation. Reloading the entire solution avoids these issues and ensures projects are loaded efficiently.

More responsive editing and debugging

In addition to the improvements above, there are numerous other improvements around language services, debugging and test experiences to ensure you have a more responsive editing and debugging environment in Visual Studio 2017.

Some highlights are:

• Better utilization of memory for users working with C#, Visual Basic and TypeScript projects, by moving parts of the language service out of process. This not only allows you to work with larger solutions in Visual Studio, but also improves typing responsiveness because of reduced GC times in the Visual Studio process.
• Faster configuration switching when working with managed and native projects either using “Lightweight Solution Load” or normal solution mode. For example, changing configuration in Roslyn’s Compilers solution while using Lightweight Solution Load is now up to 10 times faster.
• Removal of the hosting process from managed projects and significant improvements in start debugging. These fixes reduce responsiveness issues when loading projects or stopping debugging. Improvements in the start debugging scenario were made to offset the gains the hosting process provided, but they also apply to cases where the hosting process was not used. If you were not utilizing the hosting process in your projects before, these improvements will mean debugging will start faster in Visual Studio 2017.
• Added a new linker switch /Debug:fastlink to speed up incremental developer builds to support a faster edit/build/debug flow for C++ projects.
• Improved the C++ debugger to handle symbols better, allowing users to debug larger projects with lots of symbols loaded.
• Improvements to XAML editing performance and faster switching between designer tabs for UWP and XAML developers.
• Various responsiveness fixes based on telemetry to improve test discovery times and related responsiveness issues for test projects.

Be informed about your Visual Studio environment

We also wanted to show you information about performance issues as they occur. For this reason, we added a set of features to help you understand what is impacting certain key scenarios and provide workarounds where possible.

• You can go to the Help -> Manage Visual Studio Performance dialog to see which extensions and tool windows are impacting startup, solution load and typing. You might also see a notification in the IDE if we detect an extension is causing significant performance issues. You can find more details about this in the feature documentation.

• You will also see a notification from the debugger regarding function evaluations that are slow and causing unexpected debugger terminations, to help improve debugging experience.
• Similarly, the debugger will also notify you if your debugging experience can be improved by loading fewer symbols.

Try Visual Studio 2017 and let us know

We welcome you to try Visual Studio 2017 either with your own projects or with the LLVM and Roslyn Compilers projects we used as examples above and see how it compares to Visual Studio 2015 for your scenarios. We are always looking for more feedback to know which improvements are working for you, which ones are not and which areas we should focus on next.

If you are seeing performance issues, please send us feedback through Visual Studio’s Report a Problem tool that you can access from Help -> Send Feedback -> Report a problem. This tool will ensure that we have the right set of data to help us analyze the issue.

In the upcoming weeks, we will share more details about how we utilize customer feedback and product telemetry to work on performance improvements, tips and tricks to help optimize performance for certain scenarios and more details on some improvements summarized above.

Bertan Aygun, Principal Software Engineer, Visual Studio Bertan works on Visual Studio IDE Performance and Reliability team, focusing on startup performance and UI responsiveness. He has been at Microsoft since 2005 working on Visual Studio most of the time.