May 30th, 2019

Performance Improvements in Visual Studio 2019

Varun Gupta
Program Manager

Performance has been a big focus area for Visual Studio 2019, with improvements in many areas, including:

  • Faster Visual Studio startup
  • Faster branch switching experience in Visual Studio
  • C++ open folder – time to IntelliSense improvements
  • Faster C++ compiler build times
  • Faster debug stepping
  • Debug extra large C++ codebases
  • Faster installation updates

Faster and clean startup

Something you’ll notice when you open Visual Studio 2019 is its new start window. The new start window is much faster than Visual Studio 2017’s start window and has been designed to present you with several options to get you to code quickly. In addition, starting with Visual Studio 2019 version 16.1, Visual Studio blocks synchronously autoloaded extensions to improve startup and solution load times. This allows you to get to your code faster.

Visual Studio 2019 Start Window
Visual Studio 2019 Start Window

Faster branch switching experience

When working with Git, part of the usual workflow is to create and work on code branches. The branch switching experience has been completely redesigned over the last 6 months. Starting with Visual Studio 2017 update 15.8, the IDE does not completely unload and reload the solution during branch switches (unless large number of projects are updated as part of the branch switching operation). To avoid context switching between the IDE and the Git command line, Visual Studio 2019 now provides an integrated branch switching experience that allows you to “stash” any uncommitted changes during the branch switch operation. You no longer need to go outside of the IDE to stash your changes before switching branches in Visual Studio.

Faster Visual Studio 2019 Git Branch Switching
Visual Studio 2019 Git Branch Switching Experience

Faster debugger stepping

Since large part of the development cycle includes stepping through and debugging code, we have worked to bring several improvements to the debugger performance.  Stepping through your code is over 50% faster in Visual Studio 2019 versus 2017.  The Watch, Autos, and Locals windows are 70% faster. Moreover, since most debugger-related windows (i.e. watch window, call stack window, etc.) are now asynchronous, you can now interact with one window in Visual Studio while waiting for information to load in another.

Faster Visual Studio 2019 Debugger Stepping
Visual Studio 2019 Debugger Stepping

Debug very large C++ codebases

Visual Studio 2019 introduces an improved debugger for C++ that uses an external 64-bit process for hosting its memory-intensive components. If you’ve experienced memory-related issues while debugging large C++ applications before, these issues should now be resolved with Visual Studio 2019. You can read how the new external debug process has addressed the current issues in our Gears of War case study.

Visual Studio 2019 Debug Large Coderbases GoW Demo
Visual Studio 2019 Debug Large Coderbases GoW Demo

Indexing and IntelliSense performance in C++ CMake Projects

The indexing is now significantly faster for code opened via Open folder, and, as a result, IntelliSense is available considerably faster, when compared to Visual Studio 2017. As an example, in the LLVM codebase, IntelliSense becomes available 2 times faster in Visual Studio 2019. Additionally, a new indexing algorithm lights up IntelliSense incrementally while the folder is being indexed, so you don’t need to wait for the entire folder to be indexed before you can be productive with your code.

Visual Studio 2019 Faster Indexing and IntelliSense
Visual Studio 2019 Indexing and IntelliSense for C++ CMake LLVM Repository

Faster C++ Build Linker time is 2x faster

C++ builds have been made faster with improvements in the C++ linker. For example, we see over 2x faster build linker times for an Unreal Engine-based AAA game.

Visual Studio 2019 Faster Build Linker time
Visual Studio 2019 Faster Build Linker time

Faster installation of Visual Studio updates

With the introduction of background downloads for updates in 16.0, you can continue working on your code for a longer time, while the update downloads in the background. At the end of the download, once the update is ready for installation, you will get a notification to let you know that you’re good to go. Using this approach, the update installation time for Visual Studio 2019 updates have decreased significantly.

Try Visual Studio 2019 and let us know

We welcome you to try Visual Studio 2019 either with your own projects or with Roslyn Compilers projects we used as examples above and see how it compares to Visual Studio 2017 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.

Author

Varun Gupta
Program Manager

Product Management, Microsoft Cloud and Enterprise.

56 comments

Discussion is closed. Login to edit/delete existing comments.

  • Jason Honingford

    Google searched tips on speeding up the debugging process in VS 2019 and found this page that made me chuckle. It’s still super slow dude even on newer PC’s.

  • 1

    I was excited to switch from 2017 to 2019. Been using it for the whole day. But I noticed it gets slower the longer I used it.. not sure if it’s a memory leak or what. I googled it to find out if it’s just me .. nope. : (
    I think I’ll go try out VS Code again… I remembered that tool loaded fast and didn’t slow down my computer over time.

  • Adam Hardin

    Performance is extremely slow (I have an i5-7500 at 3.41 GHz and 16 gigs of ram), IntelliSense doesn’t work half the time, makes productivity very hard. Honestly, this is unacceptable.

  • moovthis

    I used VS2019 for a few weeks when one of the first previews came out. Ended up uninstalling for three reasons:
    the debugging step icons turned out to be a constant source of frustration resulting in not only a breakpoint in the code but also my own pesonal workflow needing deciphering on what was actually meant vs. what I want (in, over, out).
    I was inundated with excessive warning messages "your license is about to...

    Read more
  • László Csöndes

    I guess we’re not getting a 64-bit VS in this decade then.

  • Evgeny Vrublevsky

    I wish there were an option to replace this annoying Start Window to old Start Page from VS2017. But there is no such an option, so I had to disable this Start Window completely. At least thank you that provided an option to disable this window.

  • James Lonero

    What about for C#?

  • Alexandr Golikov

    I agree with most comments. 
    1. Start page is step back.
    2. New project dialog is step back.
    3. We need x64 VS Because of memory and c# disigner (with x64 controls inheritance) problems.
    4. You blogs sre slow and not comfortable to use.

    • Giorgio Galante

      I’ve bitten the bullet and just moved to Rider full time. VS is too slow even on my Threadripper 1950X overclocked to 4.1Ghz.

  • Mike Perez

    One thing I would like to see from visual studio is a change to a 64 bit process. Obviously this is no small feat and I have read up on why you have chosen not to do so. However I have found extension performance is pretty bad due to having to fit within the 3GB process limit, and a real pain point is that I cannot have a x64 based project with an inherited base...

    Read more
    • Varun GuptaMicrosoft employee Author

      Hello Mike, Thank you for the detailed feedback. Note that ReSharper 2019.1 supports asynchronous extensions load feature.

      My colleague Mads who works on extensions and I would love to understand your feedback better. Can you email us at vssolutionload at microsoft dot com for further discussion on this. 

      Thanks!

      Varun

  • Tanguy Fautré

    The memory usage reduction and performance improvements are all well. But given that we still cannot load our C# 200+ projects solutions in Visual Studio because it’s stuck on 32-bit, we cannot use Visual Studio at all.
    Nice way of losing hundreds of developers as customers. Good thing JetBrain Rider works.

    • Varun GuptaMicrosoft employee Author

      Hi Tanguy,

      I am sorry to hear that you are experiencing loading issues. 

      I typically load Roslyn repo that has over 160 projects. I would like to investigate what’s going on in your case. Can you please Contact me at vssolutionload at Microsoft dot com? I directly work on making solution load faster, so very interested to speak to you. 

      Thanks!

      Varun