The Latest New Features of .NET 7 Confirm the Rumors: The FASTEST .NET Ever?
Tags: dotnet, csharp, news, beginners
Published: 2022-07-11 08:07:00

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](https://docs.microsoft.com/en-us/dotnet/api/system.reflection?view=net-6.0) 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](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-5/#system-reflection-performance-improvements-when-invoking-members) (_made with the package_ `BenchmarkDotNet` ) you can see **up to 3–4x faster**.

---

## On Stack Replacement (OSR) — 30% Faster

OSR ([_On Stack Replacement_](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-4/#on-stack-replacement-aka-osr)) 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.

[According to Microsoft](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-4/#on-stack-replacement-aka-osr):

> “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_](https://github.com/icsharpcode/AvaloniaILSpy) _test_) and according to [TechEmpower](https://www.techempower.com/benchmarks/), improvements can range from **10% to 30%.**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xep7qimpv176kfub7j2a.png)
 
Performance Impact (Source: [Microsoft](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-4/#performance-impact))

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](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-4/#performance-impact) [microbenchmark](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-4/#performance-impact):

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fwjbhaspifumpace611n.png)
 
Array2 microbenchamark performance (Source: [Microsoft](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-4/#performance-impact))

📚 If you want to know in how OSR works, please refer: [**OSR Document**](https://github.com/dotnet/runtime/blob/main/docs/design/features/OnStackReplacement.md)

---

## 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](https://github.com/dotnet/runtime/pull/65738) we have seen an **improvement in startup time** that, according to Microsoft, is [**up to 10–15%**](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-3/#startup-time-improvements-with-write-xor-execute-enabled)**.**

This is mainly due to a large reduction in the number of modifications after code creation at runtime.

Let’s check the [benchamarks:](https://github.com/dotnet/runtime/pull/65738)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eamg8sg5fwllqhqgenj5.png)
 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vzkvigz6by2kz43r625i.png)
 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6wbyb7esdf58661njbm3.png)
 
---

## Native AOT Improvements — 75% faster

[**Native AOT**](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-2/#nativeaot-update) (_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**](https://docs.microsoft.com/en-us/dotnet/core/deploying/ready-to-run) (_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**](https://www.mono-project.com/docs/advanced/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](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-3/#what-is-native-aot):

-   Memory usage is restricted
-   Disk space usage is lower
-   Startup time is reduced

Microsoft explains [how Native AOT works](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-3/#what-is-native-aot):

> “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](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-3/#prepare-your-apps-for-native-aot), in which the compile time is up to **73% faster** and almost **half as light:**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pdxysbq3ufttz61rwxr7.png)
 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9qd9q0wq3umxr5hfh1x0.png)
 
---

## 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](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-3/#loop-optimizations) of the loop cloning variables:

According to [Bruce Forstall](https://github.com/BruceForstall) in his [pr](https://github.com/dotnet/runtime/pull/66257):

> “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](https://docs.microsoft.com/en-us/dotnet/api/system.collections?view=net-6.0) (Size:512) . Let’s see the [benchmark provided by Microsoft](https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-3/#loop-optimizations):

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dcpl9j87j6so5f6dfaue.png)
 
---

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?