Since the official release of .NET 6, the rumors about .NET 7 and the new features it would bring started. Today .NET 7 is (almost) a reality and it seems that Microsoft is now confirming many of the rumors that we are in front of the fastest .NET version ever: .NET 7. Let’s take a look at the latest performance improvements released by Microsoft.
Improved System.Reflection Performance — 75% Faster
Starting with the performance enhancements of the new .NET 7 features, we have first the enhancement of the System.Reflection namespace. The System.Reflection namespace is responsible for containing and storing types by metadata, to facilitate the retrieval of stored information from modules, members, assemblies and more.
They are mostly used for manipulating instances of loaded types and with them you can create types dynamically in a simple way.
With this update by Microsoft, now in .NET 7 the overhead when invoking a member using reflection has been reduced considerably. If we talk about numbers, according to the last benchmark provided by Microsoft (made with the package BenchmarkDotNet ) you can see up to 3–4x faster.
On Stack Replacement (OSR) — 30% Faster
OSR (On Stack Replacement) is a great complement to tiered compilation. It allows, in the middle of the execution of a method, to change the code that is being executed by the methods that are being executed at the moment.
“OSR allows long-running methods to switch to more optimized versions mid-execution, so the runtime can jit all methods quickly at first and then transition to more optimized versions when those methods are called frequently (via tiered compilation) or have long-running loops (via OSR).”
With OSR, we can obtain up to 25% extra speed at start-up (Avalonia IL Spy test) and according to TechEmpower, improvements can range from 10% to 30%.
Performance Impact (Source: Microsoft)
Another advantage of using OSR, is that applications (especially with dynamic PGO), are improved in terms of performance due to optimization. One of the biggest improvements was seen with Array2 microbenchmark:
Array2 microbenchamark performance (Source: Microsoft)
📚 If you want to know in how OSR works, please refer: OSR Document
Reduced start-up time (Write-Xor-Execute) — 15% Faster
As we have already seen at the beginning, Microsoft has decided to focus mainly on performance improvements and this one is no exception. Now with Reimplement stubs to improve performance we have seen an improvement in startup time that, according to Microsoft, is up to 10–15%.
This is mainly due to a large reduction in the number of modifications after code creation at runtime.
Let’s check the benchamarks:
Native AOT Improvements — 75% faster
Native AOT (Ahead-of-time) is another of the new improvements and novelties that Microsoft brings this time in .NET 7. Native AOT could be considered an improved version of ReadyToRun (RTR).
To explain it quickly, AOT alone is the technology that is responsible for generating code at compile-time (not run-time). On the other hand, RTR is basically the same but focused and specialized in scenarios where the main architecture is client-server. There is also Mono AOT (which is the same but for mobile applications).
Now, Native AOT is the improvement of (simply) AOT. Based on what I explained above, Native AOT is the Microsoft technology that is responsible for generating code at compile time, but native (that’s why “Native” AOT).
This native code generation at compile time has some advantages:
- Memory usage is restricted
- Disk space usage is lower
- Startup time is reduced
Microsoft explains how Native AOT works:
“Applications start running the moment the operating system pages in them into memory. The data structures are optimized for running AOT generated code, not for compiling new code at runtime. This is similar to how languages like Go, Swift, and Rust compile. Native AOT is best suited for environments where startup time matters the most.”
In addition, they have revealed a benchmark comparing NativeAOT against ReadyToRun, in which the compile time is up to 73% faster and almost half as light:
Loop Optimizations — 21% Faster
This improvement is not very impressive but it still manages to improve performance significantly. This time Microsoft has decided to proceed with the elimination of the initialization conditions of the loop cloning variables:
According to Bruce Forstall in his pr:
“Assume that any pre-existing initialization is acceptable”
“Check condition against zero if necessary. Const inits remain as before”
These improvements allow a 21% performance increase with System.Collections.Tests.Perf_BitArrayLeftShift (Size:512) . Let’s see the benchmark provided by Microsoft:
It seems that we are in front of the next fastest .NET. What do you think? Do you think Microsoft will continue to keep the focus on speed and performance? Or what would you like to see implemented in .NET 7?
Top comments (1)
This article pulled me in because my anecdotal evidence (which myself I take with a grain of salt) has found it to be slower. I have used the previews to benchmark a few things wondering how fast it would be. It's time an again slower than .NET 6.
I'm putting that down to using previews and not finalised versions of the code, or maybe it's to do with BenchmarkDotNet but either way I'll probably stay away from it when it comes to my professional life because .NET 7 is not LTS. I'll wait for .NET 8.