As we have been working to improve the solution load experience in Visual Studio 2017, you may have read our blog about these improvements in version 15.5. With version 15.6, we have introduced parallel project load, which loads large .NET solutions twice as fast as earlier versions when you reload the same solution. This video compares the time it takes to load a very large solution from the Roslyn repository, with 161 projects, between version 15.5 and 15.6.

Parallel project load

During the first load of a solution, Visual Studio calculates all the IntelliSense data from scratch. In the previous version of Visual Studio 2017, version 15.5, we optimized the calculation of IntelliSense data by parallelizing the design-time build that produces the data. Solutions that were opened for the first time on a machine loaded significantly faster because of this parallelization. IntelliSense data was cached, so subsequent loads of a solution didn’t require a design-time build.

With version 15.6 we wanted to go one step beyond optimizing IntelliSense calculation. We’ve enabled parallel project load for large solutions that contain C#, VB, .NET Core, and .NET Standard projects. Many Visual Studio customers have machines with at least 4 CPU cores. We wanted to leverage the power of all the CPUs during solution load by loading projects in parallel.

We continuously monitor solution load telemetry coming in through the Customer Experience Improvement Program. We saw that, in aggregate, customers experienced a 25% improvement in solution load times in version 15.6, across all solution sizes. Large .NET solutions experienced even larger improvements, and now load twice as fast as previous versions. A customer with a very large, 400+ project solution told us that their solution now loads 2-4 times faster!

Solution load is getting leaner

Parallel solution load is part of the work we’re doing to improve solution load. Another big effort is to get unneeded components out of the way of solution load. Historically, many components and extensions used solution load to perform initialization work, which added to the overall solution load time. We are changing this to make Visual Studio developers productive as quickly as possible. Only critical code that enables navigation, editing, building, and debugging will run during solution load. The rest of the components initialize asynchronously afterwards.

For example, Visual Studio previously scanned git repositories during solution load to light up the source control experience. Not anymore. This process now starts after the solution has loaded, so you can start coding faster.

As another example, Visual Studio used to synchronously initialize the out-of-process C# language service. This code is now optimized to reuse data structures already available in the Visual Studio process. We’re also working with extension owners to delay operations that do not impact the solution load process until after the load has completed.

We have also optimized the Visual Studio solution loader to batch and run all critical solution load operations before any other work can run. Previously, the Visual Studio solution loader fired a subset of solution load events asynchronously. This allowed lower priority work to interfere with solution load. Additionally, there are popular extensions that listen to these events and can block Visual Studio for seconds. This experience confused some customers, because it was not clear when solution load was complete. This logic is now optimized, so that all solution load events fire synchronously during solution load.

While solution load is significantly faster in version 15.6, we are not done yet. You will see us making solution load even leaner in future updates.

Know what slows you down

Even with these improvements, it’s still possible for slow blocking operations to get scheduled after the solution has loaded. When this happens, the solution appears loaded, but Visual Studio is unresponsive while it is processing these operations. Visual Studio version 15.6 detects blocking operations and presents a performance tip. This helps extension authors find these issues and gives end users more control over their IDE’s performance.

Extension authors can use an asynchronous API that allows extensions to run code without blocking users. We’ve also published guidance for extension authors to learn how to diagnose and address responsiveness issues. If you regularly see unresponsiveness notifications for an extension, reach out to the owner of the extension or contact us at vssolutionload@microsoft.com.

Let us know

We would love to know how much faster your solution loads in version 15.6. Give it a try and let us know by sending an email to vssolutionload@microsoft.com. You can also tweet about it and include @VisualStudio.