Visual Studio 2022 continues to be faster with each version. In this blog post we will highlight a couple of the more significant enhancements you’ll experience in 17.11, such as a more efficient C# language service, faster conditional breakpoints and symbol searches in C++.

Reduced CPU usage by C# language service

Code Indexing

In 17.10 we revamped the code indexing system in the C# language service (Roslyn). It used to be both aggressive and highly intermittent.  This would lead to high spikes of CPU usage, taking resources away from the operations users were performing, especially during times like solution load.  After opening a solution, users who wanted to wait for VS to settle would have to wait up to minutes watching a progress bar titled “Running low priority background processes”.

Now, we no longer preemptively run all the indexers.  Instead, individual ones are run on demand.  In 17.11, these indexers were further streamlined, and made much more incremental, allowing them to consume far less resources when absorbing any change into the index. In addition, there were memory allocation optimizations throughout the editor and managed language services. The net effect of this is a more responsive VS that is ready to go at a much sooner time, with much lower CPU consumption.

Source Generators

As part of our continued work to break VS into isolated, high performance, services, Roslyn’s Source Generator execution host was moved out of the main VS process to a high-performance .NET 8 host.  This helps make VS more resilient to bugs in source generators and allows them to execute much more efficiently.  As part of this work, we also changed the execution model for source generators to no longer run automatically, due to the heavy impact that some generators can still have on the system.  Instead, by default, generators will now run when a document is saved, or a project is built, greatly cutting down on the impact of all generators (especially very expensive ones).  This behavior can be controlled here:

Tools > Options > Text Editor > C# > Advanced > Source Generators

With the above changes in place, our data shows improved metrics in 17.11. CPU usage is down by 16% percent or more in sessions that had heaviest CPU usage. The C# completion list now appears sooner; looking at the slowest sessions the number of times the list takes longer than 0.5 seconds to appear has been cut by about 40%.

Improved conditional breakpoint performance

In 17.11 we made several changes to improve the performance of conditional breakpoints in C++. The improvements were primarily in two categories:

• Avoiding expensive Windows debugging API calls. Windows calls to get and set information about the debugged process can be expensive, so the data was cached to reduce the number of calls to these APIs. Additionally, some of the information was already available through other sources, allowing some calls to be eliminated entirely.
• Reducing data fetched from the debugged process. When a breakpoint is hit, the debugger must fetch a lot of information about the state of the debugged process. This is needed to populate things such as the locals tool window, the Diagnostics Tools window etc. However, to evaluate whether a conditional breakpoint’s conditions have been met, we need only a subset of that information. Now we fetch only the necessary pieces of information.

With these optimizations in place, we measured up to ~67% reduction in debugger overhead in a test application compared to 17.10.

Optimized Symbol Search for C++ language service

In 17.11 we reimplemented the text indexing system for C++ symbols. Before this change, C++ language service processed the symbol text directly to answer All-in-one-Search (AIOS) queries. We would load all the text into memory and traverse it to find matching candidates. This approach was relatively fast, but not optimal; not to mention having to keep the text cached in memory. In 17.11 we started using SQLite’s FTS5 search extension. The index is computed when the solution is parsed after it is opened, and then the language service can perform Symbol Search without any additional loading of text into memory. All the results are available faster and with less memory usage: we’ve seen the slower AIOS symbol searches up to 65% faster in 17.11. We hope you’re experiencing this improvement in your larger codebases.

Share your feedback and stay connected with Visual Studio!

We appreciate the time you’ve spent reporting issues/suggestions and hope you continue to give us feedback when using Visual Studio on what you like and what we can improve. Your feedback is critical to help us make Visual Studio the best tool it can be! You can share feedback with us via Developer Community: report any bugs or issues via report a problem and share your suggestions for new features or improvements to existing ones.

Stay connected with the Visual Studio team by following us on YouTube, Twitter, LinkedIn, Twitch and on Microsoft Learn.

On behalf of the entire Visual Studio team, thanks for reading and Happy Coding!