Visual Studio 2022 – 17.8 Performance Enhancements

Nayana Srikanth

November 22nd, 202320 4

 

Version 17.8 welcomes an array of exhilarating performance enhancements, including Improved Razor/Blazor Responsiveness, Enhanced F5 Speed, Optimized IntelliSense for C++ Unreal Engine and Build Acceleration for Non-SDK style .NET Projects.  At the heart of these changes is our commitment to enhancing performance, providing an ideal platform for a coding experience that is not only seamless but also highly productive. Embrace these improvements for a more efficient coding journey. Get ready for an exciting experience! 

Improved Razor/Blazor Responsiveness

Solutions using Razor and Blazor will experience better responsiveness. We achieved this by significantly reducing memory allocations during cross-process communications between Visual Studio and Roslyn. We tested the OrchardCore solution, and the results are impressive. To open the solution and get Razor intellisense ready, we allocate about 1.4GB less memory. Fewer heap allocations mean less work for the garbage collector, which results in improved responsiveness. 

Enhanced F5 Speed 

We’ve substantially enhanced F5 performance for native projects by optimizing how breakpoints get set up. The improvements seen by any given project depends on the number of files with breakpoints, the number of DLLs with symbols, etc.  Additionally, we’ve optimized the PDB loading process for Windows applications, reducing the time required to load a PDB once it’s located.  In our testing, these optimizations delivered a remarkable 20% speed improvement for Unreal Editor projects. 

Image debuglaunchbp

Optimized IntelliSense for C++ Unreal Engine 

We’ve made improvements to the speed with which IntelliSense and colorization become available after opening a previously opened C++ file. We have always cached IntelliSense state for an opened file. In 17.8, we’ve restructured the reading from cache, such that the most critical information, including colorization and the highlighting of selected references, are computed first. This optimization helps you get productive sooner. 

Image Intellisense New

Build Acceleration for Non-SDK style .NET Projects 

Visual Studio 17.8 extends Build Acceleration to managed applications targeting the non-SDK style projects (e.g. projects targeting .NET Framework 4.8 or lower) providing a substantial impact on build times. To enable, set an msbuild project property as follows:  

 <Project> 

        <PropertyGroup>  

              <AccelerateBuildsInVisualStudio>true</AccelerateBuildsInVisualStudio>

       </PropertyGroup>  

</Project>   

This builds on the success introduced in 17.5 for SDK-style projects, reducing incremental build times significantly.  

In our internal testing with in-house solutions, we noticed up to a 50% improvement in incremental build times.  However, the actual improvement depends on the state of projects when the build begins.  Specifically, the fewer the projects that have been modified in comparison to the total projects in the solution, the greater the improvement. The actual extent of improvement you experience will depend on the specific characteristics of your project and its modifications. 

We value your opinion!  

We believe these performance enhancements will significantly improve your development experience, making it more efficient and enjoyable. Your feedback is crucial in helping us enhance the product and meet your expectations. We encourage you to provide feedback with us via Developer Community: report any bugs or issues via Report-a-Problem and share your suggestions.  Alternatively, feel free to leave your comments below. We appreciate your input and look forward to continuously improving Visual Studio with your valuable insights. 

 

 

 

Nayana Srikanth Senior Product Manager

Read next

20 comments

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

  • Michael Taylor 0

    I’m baffled with the newer terminology being used in regards to the build acceleration documentation and I cannot be the only one struggling with this. When I read about build acceleration it ultimately talks about enabling the `AccelerateBuildsInVisualStudio` property (previously only available with .NET 5+ SDK projects). I have been using SDK-projects for years on my class library projects targeting .NET Framework and .NET 6+. It just works. My understanding of build acceleration is that it moves some of the previous MSBuild work directly into VS and that is fine as well. I get it.

    I added the property to my .NET472, net6, net8 class library project and I enabled logging to see if it is doing anything. As I expected net6/net8 is fine. But net472 compilation says I also need to set `ProduceReferenceAssembly` to true. This is set for net 6/8 already. So now I’m looking into the documentation for what this property does and is just mindblowingly low level jargon about reference assemblies (vs other types of assemblies)?? There are various Github issues around this as well but ultimately I’m a library writer who needs to support net472, net6 and net8. It seems like setting this property should be fine but it generates a message for my net472 builds and it is utterly unclear whether this is actually going to cause me problems or not if I set it.

    From my understanding I should be able to enable build acceleration and it should be fine for net 6/8 compilations but it is not clear whether my library should be setting this ‘ProduceReferenceAssembly` property (and conditionally for net472) or not and how to tell if it is going to mess up net472 clients if I do. I would like to see clearer documentation on what we should be doing here or if, like most everything else, we should only be setting it when using net 6/8. But at that point it seems odd that this property has been enabled for net standard projects when they don’t produce reference assemblies since it is really unclear what that property actually means and when we should (or shouldn’t) be using it with net standard code and how to validate whether it is breaking things or not.

    • Jackson DavisMicrosoft employee 0

      Michael, the new Build Acceleration feature discussed above only applies to non-sdk legacy projects and should not require ProduceReferenceAssembly to be set to true. Is your class library an SDK style project that is using the target framework to target net472? I am checking with the dev that wrote that to see if that is missing functionality.

      Thanks

      Jackson Davis – MSFT

      • Michael Taylor 0

        Yes it is an SDK-style class library. We multi-target net472, net6 and net8.

    • Drew NoakesMicrosoft employee 0

      Hi Michael,

      Thanks for taking the time to share your thoughts and experience. I’ll do my best to help.

      Using SDK-style projects to target multiple frameworks is a valid and supported scenario that works well with Build Acceleration. You’re hitting an issue that can happen when you target earlier than .NET 5 (including .NET Standard). There’s nothing to worry about here. The guidance is just to set <ProduceReferenceAssembly>true</ProduceReferenceAssembly> in your project, unconditionally. Then Build Acceleration will be able to do a better job. I have some ideas of how to improve this for future.

      <PropertyGroup>
  <AcceleratedBuildsInVisualStudio>true</AcceleratedBuildsInVisualStudio>
  <ProduceReferenceAssembly>true</ProduceReferenceAssembly>
</PropertyGroup>

      I’ve added some more content to our documentation in https://github.com/dotnet/project-system/pull/9342. Feel free to comment on the PR if anything’s missing or unclear.

      • Michael Taylor 0

        Thank you Drew. Yes I read about adding the `ProduceReferenceAssembly` property to resolve the issue and I started to do that. But I was curious about two things:

        1. The discussion around this property (and reference assemblies) is clearly for those who are waist deep in .NET internals and not for a .NET developer. I don’t understand what a reference assembly is, why it was enabled for .NET 5+ projects but not for .NET Framework projects and, most importantly, what impact it has enabling this for NF?
        2. If there is no real issue with NF projects setting this flag then why wouldn’t it be on by default, at least when you enable the accelerated build? It seems like there are cases where this may not work but the docs are unclear as to how we should be testing this to ensure our clients don’t have issues.

        • Drew NoakesMicrosoft employee 0

          Hi Michael, I hope the PR I linked includes details for both your questions. If not I can extend those docs. The short answer is 1) it speeds up your builds, and 2) we tried changing the default for old frameworks too, and backed it out due to rare edge cases. We take backwards compatibility very seriously, though you are incredibly unlikely to see any issues from the feature.

  • Stuart Ballard 4

    Speaking of build improvements, my biggest pet peeve with VS for a couple decades now is that if you build a solution and there’s a compile error in one project, it will still try to build all the other projects that depend on the broken one, which is at best a complete waste of time and at worst introduces a ton of nonsense errors claiming that methods don’t exist when they clearly do (because they were added after the last successful build of the lower level project and therefore aren’t in the dll). It seems like a no brainer to skip building a project if it references another project in the same solution that failed to build. Is there any reason why VS _doesn’t_ do that? Any prospect of it ever changing?

    • Drew NoakesMicrosoft employee 3

      Great suggestion. I’ve got two links for you:

      – Firstly, a feedback ticket that you can vote on.
      – Secondly, the StopOnFirstBuildError VS extension that will achieve what you want.

      • Stuart Ballard 1

        Thanks – I voted and commented on the feedback ticket! The behavior I’m looking for is subtly different from “stop on first build error” – I’d like the build to continue for other projects that don’t depend on the failing one – but stopping on the first error is definitely an improvement on the status quo so I’ll check out that extension as well!

        • Drew NoakesMicrosoft employee 0

          You’re right. I updated the link in my post above too to avoid confusion. Thanks.

  • Johan Visser 0

    I found that after updating Visual Studio or updating 1 or more extensions, opening my solution takes twice as long the first time.
    After that it is back to normal.

    • Drew NoakesMicrosoft employee 0

      Hi Johan. That’s not unexpected. VS upgrades and changes to the set of installed extensions commonly cause caches to be invalidated, and they need to be rebuilt on the next launch.

  • Gopi Ch 1

    Is there any plan for reducing the build time in VS ??

  • Mike-E 0

    Thank you for all your efforts to improve. 🙏🦃 It would be great to see you work on addressing 40+-second build times for a single key press in Blazor projects:
    https://github.com/dotnet/razor/issues/6919#issuecomment-1702455259

    This problem has been increasing with the more Razor that I add to my solution. Thank you for your consideration.

  • Eugene Ivanoff 0

    Triple quotes still do not work in Razor Editor

  • Daniel Silver 0

    Hello, I have a project which extensively uses SSE, AVX2 and AVX512 intrinsics. With this update, my code is throwing exceptions due to invalid instructions. The compiler is generating very invalid code using registers greater than ymm15. Take this code, for example:

    mov         qword ptr [rsp+18h],rbx  
push        rbp  
push        rsi  
push        rdi  
sub         rsp,1D0h  
lea         rbp,[rsp+40h]  
and         rbp,0FFFFFFFFFFFFFFE0h  
mov         rax,qword ptr [__security_cookie (07FFFC55BB040h)]  
xor         rax,rsp  
mov         qword ptr [rbp+180h],rax  
vmovups     ymm16,ymmword ptr [r8+20h]
vmovups     ymm17,ymmword ptr [r8]

    You can see the MSVC compiler has emitted AVX2 code using registers ymm16 and ymm17. This is totally invalid as the AVX2 spec has only 16 ymm registers.

    Here is another example:

    vcvtpd2dq   xmm18,ymm1  
vsubpd      ymm30,ymm2,ymm0

    Are you starting to enable for AVX10? Because it looks like this code is only valid when running on a CPU with AVX512 support or the upcoming AVX10 spec where its possible to use up to 32 registers on the 256-bit ymm registers. But this won’t run on anything except AVX512 and future processors.

    There is nothing I can do on my end to prevent this code generation, other than to roll back to a previous version of the compiler (which I did verify rolling back solved the problem). This is really scary!

  • Nathan Ferreira 0

    What about to support other important languages such as Rust and Dart inside VS? And at least add support to Flutter inside VS2022.

  • Jay Davidson 0

    This new version still has the (intermittent) problem of hanging when you open a solution/project. I updated yesterday and It just happened – hung for ~ 10 mins. AND then Task Manager locked up the computer trying to kill the VS2022 process!! Had to do a cold reboot!

Feedback usabilla icon