{"id":60786,"date":"2026-09-15T05:00:00","date_gmt":"2026-09-15T12:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=60786"},"modified":"2026-09-14T21:06:16","modified_gmt":"2026-09-15T04:06:16","slug":"performance-improvements-in-net-11","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/performance-improvements-in-net-11\/","title":{"rendered":"Performance Improvements in .NET 11"},"content":{"rendered":"

Before television shows like The Office<\/em> and Parks and Recreation<\/em> cemented the mockumentary in the minds of millions, there was Christopher Guest. He didn’t invent the genre, but he’s widely recognized as one of its most influential practitioners, and for my money, there’s none better. I’ve watched Waiting for Guffman<\/em> and Best in Show<\/em> more times than I can count. But the one that has stuck with me the most, the one I quote at the slightest provocation, is This Is Spinal Tap<\/em>.<\/p>\n

If you’ve seen it you already know where this is going (and if you haven’t, you now have weekend plans). The film is a fictional documentary about an aging English rock band named Spinal Tap, whose members are everything we picture when we picture over-the-top rock stars. In one of its more memorable scenes, the guitarist (Nigel) gives the filmmaker (Marty) a tour of his most prized gear, in particular showing off an amplifier unlike any other: its dials don’t stop at ten. That leads to what might be the single most quoted exchange in the entire movie:<\/p>\n

Nigel:<\/strong> “You see, most blokes, you know, will be playing at ten. You’re on ten here, all the way up, all the way up, all the way up, you’re on ten on your guitar. Where can you go from there? Where?”<\/p>\n

Marty:<\/strong> “I don’t know.”<\/p>\n

Nigel:<\/strong> “Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?”<\/p>\n

Marty:<\/strong> “Put it up to eleven?”<\/p>\n

Nigel:<\/strong> “Eleven. Exactly. One louder.”<\/p><\/blockquote>\n

This is .NET 11. It’s one louder, with another year’s worth of performance work\nhaving gone into making the runtime and libraries that much faster. Of course, the premise of Nigel’s special amplifier is ludicrous, as is exemplified in the subsequent few lines of dialog:<\/p>\n

Marty:<\/strong> “Why don’t you just make ten louder and make ten be the top number and make that a little louder?”<\/p>\n

Nigel:<\/strong> (pauses) “…these go to eleven.”<\/p><\/blockquote>\n

In contrast, .NET 11 is actually one higher, one louder. The sections that follow are full of real improvements. A bounds check removed, an allocation that no longer happens, a lock that isn’t taken, a loop that runs in fewer cycles than it did a year ago, a comparison folded to a constant here, a redundant check hoisted out of a loop there, a couple of instructions fused into one, a syscall sidestepped, an array copy handed off to SIMD, and on and on. That’s how real performance work goes, accumulating gain after gain, each compounding on the last, until the whole thing is measurably, provably louder. And so, in this post, as I’ve done in past years with .NET 10<\/a>, .NET 9<\/a>, .NET 8<\/a>, .NET 7<\/a>, .NET 6<\/a>, .NET 5<\/a>, .NET Core 3.0<\/a>, .NET Core 2.1<\/a>, and .NET Core 2.0<\/a> before it, we’ll take an unhurried tour through hundreds of them.<\/p>\n

This is a long one. It’s meant to be. Grab your hot beverage of choice, settle in, and let’s turn it up.<\/p>\n

Benchmarking Setup<\/h2>\n

As in previous years, the post is chock full of micro-benchmarks that demonstrate the individual improvements. Almost all of them use BenchmarkDotNet<\/a>, and each is written to be self-contained so you can try it out yourself.<\/p>\n

Start by ensuring you have both .NET 10<\/a> and .NET 11<\/a> installed (most of the benchmarks compare the same code running on both versions) and create a new console project in a fresh benchmarks<\/code> directory:<\/p>\n

dotnet new console -o benchmarks\r\ncd benchmarks<\/code><\/pre>\n
Replace the contents of the generated benchmarks.csproj<\/code> with the following, which multi-targets both versions so that BenchmarkDotNet can build for each:<\/p>\n
<Project Sdk=\"Microsoft.NET.Sdk\">\r\n\r\n  <PropertyGroup>\r\n    <OutputType>Exe<\/OutputType>\r\n    <TargetFrameworks>net11.0;net10.0<\/TargetFrameworks>\r\n    <LangVersion>preview<\/LangVersion>\r\n    <ImplicitUsings>enable<\/ImplicitUsings>\r\n    <Nullable>enable<\/Nullable>\r\n    <AllowUnsafeBlocks>true<\/AllowUnsafeBlocks>\r\n    <ServerGarbageCollection>true<\/ServerGarbageCollection>\r\n    <SystemPackageVersion Condition=\"'$(TargetFramework)' == 'net10.0'\">10.0.12<\/SystemPackageVersion>\r\n    <SystemPackageVersion Condition=\"'$(TargetFramework)' == 'net11.0'\">11.0.0-rc.1.26425.128<\/SystemPackageVersion>\r\n  <\/PropertyGroup>\r\n\r\n  <ItemGroup>\r\n    <PackageReference Include=\"BenchmarkDotNet\" Version=\"0.16.0-preview.1\" \/>\r\n    <PackageReference Include=\"System.IO.Hashing\" Version=\"$(SystemPackageVersion)\" \/>\r\n    <PackageReference Include=\"System.Runtime.Caching\" Version=\"$(SystemPackageVersion)\" \/>\r\n    <PackageReference Include=\"System.Numerics.Tensors\" Version=\"$(SystemPackageVersion)\" \/>\r\n  <\/ItemGroup>\r\n\r\n<\/Project><\/code><\/pre>\n
For a given benchmark to test, copy its complete contents over everything in Program.cs<\/code> and then run it. Each benchmark includes as a comment at the top the exact command to use. In most cases, it’s:<\/p>\n
dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0<\/code><\/pre>\n
which builds in Release and runs the benchmark against both .NET 10 and .NET 11, emitting a side-by-side comparison. The other common form, used when a benchmark is comparing two coding approaches on a single runtime (rather than the same code across two runtimes) is:<\/p>\n
dotnet run -c Release -f net11.0 --filter \"*\"<\/code><\/pre>\n
The usual disclaimer applies: these are micro-benchmarks, many measuring operations so short that a blink would miss them. Your results will vary with your hardware, OS, runtime configuration, what else your machine happens to be doing at that exact moment, and whether Mercury is in retrograde.<\/p>\n
Every line of managed code ultimately ends up at the just-in-time compiler, so let’s start there.<\/p>\n
JIT<\/h2>\n
Of all the places to improve .NET’s performance, few have as broad an impact as the just-in-time (JIT) compiler. C#, F#, and Visual Basic are typically compiled first to intermediate language (IL), and the JIT ultimately turns that IL into the native instructions the CPU executes. A JIT improvement can therefore benefit application and library code wherever the optimized pattern occurs, often with no source changes or recompilation of the application itself. Even removing a single instruction or proving one check unnecessary can add up when the code is on a very hot path.<\/p>\n
Deabstraction<\/h3>\n
We as developers love our abstractions. They let us write clean, reusable, object-oriented code, but we don’t want to pay for every abstraction at run time. The runtime can often undo an abstraction when it proves the effects aren’t observable. It can look at a virtual call and determine which concrete method it’ll invoke, look at a heap allocation and recognize that the object never leaves the current stack frame, or look at an interface cast and reuse a type fact already established earlier in the method. This process is called “deabstraction.” .NET has improved steadily in this area for years, and that continues in .NET 11.<\/p>\n
Every time you write interface<\/code> in C#, you’re creating a contract, a promise that any type implementing that interface can be substituted for any other. That flexibility is enormously valuable because, for example, it’s what lets us write IEnumerable<T><\/code> and have it work equally well over arrays, lists, other collections, LINQ, custom iterators, and so on. But the CPU doesn’t know anything about these contracts; it just knows how to execute instructions. Turning “call whatever method this interface reference points to” into actual machine instructions requires special machinery. Consider this example:<\/p>\n
\/\/ dotnet run -c Release -f net11.0 --filter \"*\"\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[DisassemblyDiagnoser, HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private Animal _animal = Environment.TickCount >= 0 ? new Dog() : new Cat();\r\n\r\n    [Benchmark]\r\n    public int Speak() => _animal.Speak();\r\n\r\n    public abstract class Animal\r\n    {\r\n        public abstract int Speak();\r\n    }\r\n\r\n    private sealed class Dog : Animal\r\n    {\r\n        [MethodImpl(MethodImplOptions.NoInlining)]\r\n        public override int Speak() => 1;\r\n    }\r\n\r\n    private sealed class Cat : Animal\r\n    {\r\n        [MethodImpl(MethodImplOptions.NoInlining)]\r\n        public override int Speak() => 2;\r\n    }\r\n}<\/code><\/pre>\n
At compile time, all else equal, the JIT doesn’t know whether _animal<\/code> is a Dog<\/code> or a Cat<\/code>. It generates code that loads the instance’s “method table pointer” (its object type handle), sometimes called a “vtable pointer”, stored at the beginning of every .NET object, indexes into the method table at the known slot for Speak<\/code>, and calls the function pointer found there:<\/p>\n
; x64\r\nmov     rcx, [rcx+8]   ; load _animal\r\nmov     rax, [rcx]     ; load method table\r\nmov     rax, [rax+40]  ; load vtable chunk\r\ncall    qword ptr [rax+20]<\/code><\/pre>\n
For this one call to Speak<\/code>, we pay three dependent memory dereferences and an indirect call because the processor doesn’t know for certain in advance where the call is going (it might guess, or “speculatively execute”, but it has to be prepared for the possibility it was wrong), and because the call target is indirect, the JIT can’t inline the callee. Whatever Speak<\/code> does, its code can’t be folded into the calling method.<\/p>\n
That’s a performance problem. Those indirections have overhead, but the bigger cost is the lost opportunity to inline. Inlining not only saves function call overhead, more importantly it opens the callee’s code up to the same optimizations that are operating on the caller, such as constant propagation, dead code elimination, bounds check elimination, further devirtualization, etc. That means a series of small virtual calls that each look innocent can, when devirtualized and inlined, collapse into a handful of instructions that would be unrecognizable and way cheaper when compared to the original source code. Without inlining, each callee is an opaque box; with it, the JIT can see through the layers.<\/p>\n
We as .NET developers constantly rely on the JIT’s sophisticated heuristics for inlining that weigh the IL size of the callee, the exact work the callee is performing, the call frequency of the method, the expected benefit from constant arguments, and dozens of other factors. For virtual calls, the JIT needs to know what the actual target of the call will be; it needs to “devirtualize”. In some cases, it can determine that statically, where it has exact-type knowledge. For example, if the JIT can prove that animal<\/code> is always a Dog<\/code>, whether because it was just allocated with new Dog()<\/code>:<\/p>\n
Animal animal = GetSomeAnimal();\r\nanimal.Speak();\r\n...\r\nstatic Animal GetSomeAnimal() => new Dog(); \/\/ inlineable<\/code><\/pre>\n
or because the variable’s type is a sealed class:<\/p>\n
Dog animal = GetSomeAnimal();\r\nanimal.Speak();\r\n...\r\nsealed class Dog { ... } \/\/ impossible for `animal` to be anything other than a `Dog`<\/code><\/pre>\n
or with NativeAOT and whole-program compilation, if it sees that Animal<\/code> is abstract and the only type in the whole application that derives from Animal<\/code> is Dog<\/code>:<\/p>\n
Animal animal = GetSomeAnimal();\r\nanimal.Speak();\r\n...\r\nabstract class Animal { ... }\r\nclass Dog : Animal { ... } \/\/ no other such derived type<\/code><\/pre>\n
or other such validation, it can emit a call to Dog.Speak()<\/code> directly, and the inliner can take its shot.<\/p>\n
But for other cases where it can’t prove this with static analysis, the JIT turns to profile-guided optimization (PGO). PGO sounds fancy, but it’s conceptually simple. With “tiered compilation”, when a method is first invoked, it can be compiled “just in time” with few-to-no optimizations (this is referred to as Tier 0). The JIT can include in this compilation additional probes (think “printf debugging”) that let it track a bunch of interesting information about the nature of the code, recording what actually happens when it runs: which branches are taken, what are the concrete types that show up at virtual call sites or cast attempts, and so on. If the method is invoked enough or loops enough times, the runtime can ask the JIT to produce a new optimized version (referred to as Tier 1). That compilation can then factor in all of the learnings gathered as part of that profiling.<\/p>\n
The JIT, of course, still needs to generate code that’s always correct. Even if a dynamic profile says animal<\/code> was Dog<\/code> 100% of the time, that doesn’t guarantee it’ll always be Dog<\/code> in the future; it could be that the first 1000 calls passed in a Dog<\/code> but the 1001st call is going to pass in Dolphin<\/code>. How can the JIT incorporate this learning then? By emitting a run-time check. The Dog<\/code> path can get a direct call, which may then be inlinable, and the other path keeps the original virtual call as the fallback. The speed comes from making the common case tiny, while correctness comes from leaving the uncommon case intact.<\/p>\n
\/\/ Approximately what the JIT generates\r\nif (animal?.GetType() == typeof(Dog))\r\n{\r\n    ((Dog)animal).Speak();  \/\/ devirtualized, inlinable\r\n}\r\nelse\r\n{\r\n    animal.Speak(); \/\/ original virtual call, hopefully rare\r\n}<\/code><\/pre>\n
This “guess and verify” pattern, called “guarded devirtualization” (GDV), accounts for many of the biggest throughput wins in real workloads. It’s applicable not only to virtual dispatch but also to interface dispatch, which also happens to be a bit more expensive than virtual dispatch because a type can implement any number of interfaces and that means the interface slots don’t simply map to fixed vtable positions.<\/p>\n
Deabstraction can also make object creation more efficient when it reveals what kind of object is involved. In general, objects in .NET are allocated on the garbage collected heap, tracked by the garbage collector (GC), and collected when no longer reachable. Heap allocation is typically fast, often effectively just bumping a pointer. However, when there’s not enough space available to bump the pointer, it can get much more expensive, including needing to incur a garbage collection. Every allocated object also effectively incurs the amortized cost of all collections, as every allocated object eventually needs to be cleaned up.<\/p>\n
“Escape analysis” is the compiler technique that lets us ask whether this object ever “escapes” the current method. If an object reference to a newly allocated object provably doesn’t escape, then the JIT can more efficiently allocate it. It needn’t store it on the GC heap, because nothing could possibly need to reference that object again, so it can instead allocate the object on the stack, making both allocation and cleanup essentially free. Stack allocation is even faster than heap bump-pointer allocation; it’s just decrementing the stack pointer, which is typically already in a register. And more importantly it means zero GC impact, because the stack frame is freed atomically on function return.<\/p>\n
The JIT’s been progressively expanding escape analysis over the past several .NET releases, with .NET 9 and 10 seeing significant investments in stack-allocating delegates and closures, Nullable<T><\/code> temporaries, and small helper objects. The key theme is that every false positive escape, every time the JIT incorrectly concludes an object may escape when it really doesn’t, represents a heap allocation that could have been avoided, and we want to whittle away at that false positive list. In .NET 11, the JIT trims that list in several ways.<\/p>\n
We’ll start with nullable boxing. Consider this benchmark:<\/p>\n
\/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[MemoryDiagnoser(false), HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private int? _nullableNull;\r\n    private int? _nullableValue = 42;\r\n\r\n    [Benchmark]\r\n    public object? BoxNullableNull() => (object?)_nullableNull;\r\n\r\n    [Benchmark]\r\n    public object? BoxNullableValue() => (object?)_nullableValue;\r\n\r\n    [Benchmark]\r\n    public string? FormatNullableInt() => Format(_nullableValue);\r\n\r\n    private static string? Format<T>(T value)\r\n    {\r\n        if (value is IFormattable formattable)\r\n            return formattable.ToString(null, null);\r\n\r\n        return null;\r\n    }\r\n}<\/code><\/pre>\n\n\n\n\n\n\n\n\n\n\n
Method<\/th>\nRuntime<\/th>\nMean<\/th>\nRatio<\/th>\nAllocated<\/th>\nAlloc Ratio<\/th>\n<\/tr>\n<\/thead>\n
BoxNullableNull<\/td>\n.NET 10.0<\/td>\n2.095 ns<\/td>\n1.00<\/td>\n–<\/td>\n–<\/td>\n<\/tr>\n
BoxNullableNull<\/td>\n.NET 11.0<\/td>\n1.764 ns<\/td>\n0.84<\/td>\n–<\/td>\n–<\/td>\n<\/tr>\n
BoxNullableValue<\/td>\n.NET 10.0<\/td>\n9.213 ns<\/td>\n1.00<\/td>\n24 B<\/td>\n1.00<\/td>\n<\/tr>\n
BoxNullableValue<\/td>\n.NET 11.0<\/td>\n4.126 ns<\/td>\n0.45<\/td>\n24 B<\/td>\n1.00<\/td>\n<\/tr>\n
FormatNullableInt<\/td>\n.NET 10.0<\/td>\n9.583 ns<\/td>\n1.00<\/td>\n24 B<\/td>\n1.00<\/td>\n<\/tr>\n
FormatNullableInt<\/td>\n.NET 11.0<\/td>\n1.987 ns<\/td>\n0.21<\/td>\n–<\/td>\n0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
dotnet\/runtime#122167<\/a> expands nullable boxing inside the JIT, exposing the temporary box to escape analysis; previously, a runtime helper hid it. For a null<\/code> input, there’s no allocation on either version, because nothing gets boxed. And on both versions, BoxNullableValue<\/code> returns the boxed object, meaning the object escapes, so the 24-byte allocation remains. However, for FormatNullableInt<\/code>, the JIT in .NET 11 can now see that the temporary 24-byte box doesn’t escape and eliminates that heap allocation entirely.<\/p>\n
Escape analysis improved further for enumerators, through a mechanism called Conditional Escape Analysis (CEA). Support for CEA was introduced in .NET 10, but .NET 11 extends the set of patterns that this analysis can safely recognize. The existing escape analysis asks whether a reference created by an allocation can flow somewhere the JIT can no longer track, such as an unknown call. If it can, the object must remain on the heap. That analysis is necessarily conservative and largely flow-insensitive: if an object might be passed to an interface call on any path, it doesn’t try to prove that the path containing that call is mutually exclusive with the path containing the allocation.<\/p>\n
Unfortunately, that’s exactly what GDV produces when it optimizes a foreach<\/code> over an IEnumerable<T><\/code>. As noted earlier, GDV turns an interface call into a type check with two branches: a fast branch for the likely collection type and a fallback branch containing the original interface call. Devirtualization and inlining along the fast branch will often reveal an enumerator allocation for the collection type, while later enumerator guards retain fallback calls such as IEnumerator<T>.MoveNext<\/code>. The existing analysis sees those calls and concludes that the locally allocated enumerator might escape. CEA instead records the relationship between the fast-path allocation and the enumerator local tested by the later guards. If every apparent escape occurs only behind a failed type check, the JIT can clone the region into a hot version where those checks are known to succeed. In that clone, the object can’t reach the fallback calls, so it can be stack-allocated and often promoted into separate scalar locals. The original region remains as the general slow path.<\/p>\n
One case .NET 10 didn’t handle, though, was a GetEnumerator()<\/code> implementation that returns the result of another GetEnumerator()<\/code> call. A collection expression converted to IEnumerable<int><\/code>, for example, uses a compiler-generated read-only-array wrapper with exactly this structure: the wrapper’s GetEnumerator()<\/code> delegates to the underlying array’s GetEnumerator<\/code>. With dotnet\/runtime#122946<\/a>, the JIT in .NET 11 handles this “chaining”:<\/p>\n
\/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[MemoryDiagnoser(false), HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private static readonly IEnumerable<int> s_readOnlyStatic = [1, 2, 3, 4, 5];\r\n    private readonly IEnumerable<int> _readOnlyInstance = [1, 2, 3, 4, 5];\r\n\r\n    [Benchmark]\r\n    public int ReadOnlyStatic()\r\n    {\r\n        int sum = 0;\r\n        foreach (int item in s_readOnlyStatic) sum += item;\r\n        return sum;\r\n    }\r\n\r\n    [Benchmark]\r\n    public int ReadOnlyInstance()\r\n    {\r\n        int sum = 0;\r\n        foreach (int item in _readOnlyInstance) sum += item;\r\n        return sum;\r\n    }\r\n}<\/code><\/pre>\n\n\n\n\n\n\n\n\n
Method<\/th>\nRuntime<\/th>\nMean<\/th>\nRatio<\/th>\nAllocated<\/th>\nAlloc Ratio<\/th>\n<\/tr>\n<\/thead>\n
ReadOnlyStatic<\/td>\n.NET 10.0<\/td>\n2.665 ns<\/td>\n1.00<\/td>\n–<\/td>\n–<\/td>\n<\/tr>\n
ReadOnlyStatic<\/td>\n.NET 11.0<\/td>\n2.666 ns<\/td>\n1.00<\/td>\n–<\/td>\n–<\/td>\n<\/tr>\n
ReadOnlyInstance<\/td>\n.NET 10.0<\/td>\n13.874 ns<\/td>\n1.00<\/td>\n32 B<\/td>\n1.00<\/td>\n<\/tr>\n
ReadOnlyInstance<\/td>\n.NET 11.0<\/td>\n2.674 ns<\/td>\n0.19<\/td>\n–<\/td>\n0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
ReadOnlyStatic<\/code>, whose static readonly<\/code> field the JIT can effectively treat as a constant, was already optimized in .NET 10. In .NET 11, the instance-field case also loses its 32-byte enumerator allocation and converges on the same throughput.<\/p>\n
dotnet\/runtime#121918<\/a> from @MichalPetryka<\/a> fixes another way an address could unnecessarily make an object appear to escape. The IL constrained.<\/code> prefix lets one generic callvirt<\/code> sequence work for both value types and reference types: it can avoid boxing a value type, while for a reference type it dereferences the receiver and performs normal virtual dispatch. ObjectEqualityComparer<T>.Equals<\/code>, used in the following benchmark by EqualityComparer<T>.Default<\/code>, contains such a call to value.Equals(other)<\/code>. The receiver was represented as an indirect read through the address of a local. Merely taking that address marked the local as exposed, preventing the newly allocated Value<\/code> from being considered for stack allocation. The receiver is now represented as a direct value load instead, and the 24-byte heap allocation disappears.<\/p>\n
\/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Collections.Generic;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[MemoryDiagnoser(false), HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private static readonly Value s_other = new(42);\r\n\r\n    [Benchmark]\r\n    public bool Equals() => EqualityComparer<Value>.Default.Equals(new Value(42), s_other);\r\n\r\n    private sealed class Value(int value)\r\n    {\r\n        private readonly int _value = value;\r\n\r\n        public override bool Equals(object? obj) => obj is Value other && _value == other._value;\r\n\r\n        public override int GetHashCode() => _value;\r\n    }\r\n}<\/code><\/pre>\n\n\n\n\n\n\n
Method<\/th>\nRuntime<\/th>\nMean<\/th>\nRatio<\/th>\nAllocated<\/th>\nAlloc Ratio<\/th>\n<\/tr>\n<\/thead>\n
Equals<\/td>\n.NET 10.0<\/td>\n3.874 ns<\/td>\n1.00<\/td>\n24 B<\/td>\n1.00<\/td>\n<\/tr>\n
Equals<\/td>\n.NET 11.0<\/td>\n1.786 ns<\/td>\n0.46<\/td>\n–<\/td>\n0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
While CEA can move a non-escaping object off the GC heap, sometimes the JIT can go further and prove an allocation need not exist at all. Generic code provides a common source of such opportunities through boxing. For example, the ArgumentNullException.ThrowIfNull<\/code> method accepts an object value<\/code>. That means when you have a method like this:<\/p>\n
static void Test<T>(T value)\r\n{\r\n    ArgumentNullException.ThrowIfNull(value);\r\n    ...\r\n}<\/code><\/pre>\n
when T<\/code> is constrained to a non-nullable struct, boxing is incurred, in order to pass value<\/code> as object<\/code>. ThrowIfNull<\/code> here is a nop if value<\/code> is non-null<\/code> (since the method is simply if (value is null) Throw();<\/code>), and previous releases successfully optimized away that boxing in optimized code. However, in Tier 0, that optimization wasn’t applied, and ThrowIfNull<\/code> would end up allocating. While this wouldn’t negatively impact steady-state throughput, it would lead to annoying noise in profiling, as well as additional overhead during startup, where such use wasn’t yet promoted out of Tier 0. In .NET 11, dotnet\/runtime#129392<\/a> adds support for this in Tier 0 as well.<\/p>\n
On the virtual-dispatch side, multiple PRs contribute to improving generic virtual methods (GVMs). dotnet\/runtime#120866<\/a> from @hez2010<\/a> stops eagerly spilling ldvirtftn<\/code> call targets into a temporary, and lets generic virtual target resolution move ahead of argument setup when legal. dotnet\/runtime#122023<\/a> from @hez2010<\/a> then enables the JIT to devirtualize non-shared GVMs, carrying the generic context needed to turn the indirect dispatch into a direct, and potentially inlineable, call. And dotnet\/runtime#128702<\/a> from @hez2010<\/a> extends that support to shared GVMs and default interface implementations that require an instantiating stub. These optimizations can increase total code size when the newly direct calls are inlined, but that’s generally the desired trade: more of the actual work becomes visible to the optimizer. Consider the following benchmark:<\/p>\n
\/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[MemoryDiagnoser(false), HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    [Benchmark]\r\n    public int NonShared() => ((IProcessor)new Processor()).SizeOf(42);\r\n\r\n    [Benchmark]\r\n    public int Shared() => ((IProcessor)new Processor()).SizeOf(\"hello\");\r\n\r\n    private interface IProcessor\r\n    {\r\n        int SizeOf<T>(T value);\r\n    }\r\n\r\n    private sealed class Processor : IProcessor\r\n    {\r\n        public int SizeOf<T>(T value) => Unsafe.SizeOf<T>();\r\n    }\r\n}<\/code><\/pre>\n
Casting a freshly allocated Processor<\/code> to IProcessor<\/code> incurs an interface generic virtual call in the IL, but the JIT is now able to see the receiver’s exact type, even in the shared string<\/code> case, such that .NET 11 devirtualizes and inlines both calls. That in turn exposes Unsafe.SizeOf<T>()<\/code> as a constant and proves that the short-lived Processor<\/code> doesn’t need to be allocated at all.<\/p>\n\n\n\n\n\n\n\n\n
Method<\/th>\nRuntime<\/th>\nMean<\/th>\nRatio<\/th>\nAllocated<\/th>\nAlloc Ratio<\/th>\n<\/tr>\n<\/thead>\n
NonShared<\/td>\n.NET 10.0<\/td>\n6.678 ns<\/td>\n1.00<\/td>\n24 B<\/td>\n1.00<\/td>\n<\/tr>\n
NonShared<\/td>\n.NET 11.0<\/td>\n1.764 ns<\/td>\n0.26<\/td>\n–<\/td>\n0<\/td>\n<\/tr>\n
Shared<\/td>\n.NET 10.0<\/td>\n7.166 ns<\/td>\n1.00<\/td>\n24 B<\/td>\n1.00<\/td>\n<\/tr>\n
Shared<\/td>\n.NET 11.0<\/td>\n1.764 ns<\/td>\n0.25<\/td>\n–<\/td>\n0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Building on that, dotnet\/runtime#123183<\/a> from @hez2010<\/a> enables ReadyToRun compilation to resolve and devirtualize more non-shared generic virtual calls that would otherwise remain indirect, and dotnet\/runtime#130202<\/a> from @hez2010<\/a> extends that support to NativeAOT. NativeAOT represents some generic virtual targets as “fat pointers” (pointers that are more than just an address, typically an address and associated metadata, and that in this case carry both a code address and generic context); by deferring that transformation until after exact-type devirtualization has had a chance to run, the JIT can turn an interface call site with a single known target to a non-shared GVM into a direct call that may then be inlined.<\/p>\n
Type information also needs to survive the transformations the JIT performs internally. If the JIT spills a reference expression into a temporary while restructuring a tree, losing the expression’s exact class information can turn a call that was devirtualizable back into an opaque virtual call. That’s what happens here in .NET 10: Value<\/code> gets boxed and SetValue<\/code> is invoked through IValue<\/code>. dotnet\/runtime#128485<\/a> from @hez2010<\/a> preserves the class handle and exactness on the temporary. With that information still available, .NET 11 devirtualizes and inlines the call, eliminating the box and its 24-byte allocation.<\/p>\n
Separately, dotnet\/runtime#127433<\/a> relaxes the inliner’s budget heuristics for callees on [Intrinsic]<\/code> types like Span<\/code> and Vector<\/code>. These types intentionally expose many small, composable methods that serve as gateways to JIT-recognized operations. If a wrapper remains as a call, the caller pays the call overhead and optimizations around it see an opaque boundary. If it inlines, the importer can replace its body with an intrinsic node and optimize that node together with the surrounding indexing, bounds checks, and vector operations. Giving such wrappers more favorable budgeting therefore keeps more of them inlineable and exposes more of the actual operation to the rest of the optimizer.<\/p>\n
One of the core abstraction-enabling mechanisms in .NET is delegates: they let us pass around objects representing functions to be invoked, carrying with them associated required state. Deabstraction enables avoiding paying for the overheads associated with delegates in some cases. For the rest, we still want those delegates to be as cheap as possible. dotnet\/runtime#99200<\/a> from\n@MichalPetryka<\/a> simplifies CoreCLR’s delegate\nrepresentation, removing one pointer-sized field from every delegate object.\nThat saves 8 bytes per delegate in a 64-bit CoreCLR process.\ndotnet\/runtime#129304<\/a> from\n@MichalPetryka<\/a> improves Native AOT’s\ndelegate layout separately by reordering its existing four fields so related\nvalues are adjacent. The updated layouts also give equality and hash-code\noperations more direct access to the method identity they need.<\/p>\n
\/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[MemoryDiagnoser(false), HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private static readonly Target s_target = new();\r\n    private static readonly Func<int> s_first = s_target.GetValue;\r\n    private static readonly Func<int> s_second = s_target.GetValue;\r\n\r\n    [Benchmark]\r\n    public Func<int> ClosedInstance() => s_target.GetValue;\r\n\r\n    [Benchmark]\r\n    public bool DelegateEquals() => s_first.Equals(s_second);\r\n\r\n    [Benchmark]\r\n    public int DelegateGetHashCode() => s_first.GetHashCode();\r\n\r\n    private sealed class Target\r\n    {\r\n        public int GetValue() => 42;\r\n    }\r\n}<\/code><\/pre>\n\n\n\n\n\n\n\n\n\n\n
Method<\/th>\nRuntime<\/th>\nMean<\/th>\nRatio<\/th>\nAllocated<\/th>\nAlloc Ratio<\/th>\n<\/tr>\n<\/thead>\n
ClosedInstance<\/td>\n.NET 10.0<\/td>\n7.395 ns<\/td>\n1.00<\/td>\n64 B<\/td>\n1.00<\/td>\n<\/tr>\n
ClosedInstance<\/td>\n.NET 11.0<\/td>\n6.844 ns<\/td>\n0.93<\/td>\n56 B<\/td>\n0.88<\/td>\n<\/tr>\n
DelegateEquals<\/td>\n.NET 10.0<\/td>\n3.254 ns<\/td>\n1.00<\/td>\n–<\/td>\n–<\/td>\n<\/tr>\n
DelegateEquals<\/td>\n.NET 11.0<\/td>\n2.215 ns<\/td>\n0.68<\/td>\n–<\/td>\n–<\/td>\n<\/tr>\n
DelegateGetHashCode<\/td>\n.NET 10.0<\/td>\n5.623 ns<\/td>\n1.00<\/td>\n–<\/td>\n–<\/td>\n<\/tr>\n
DelegateGetHashCode<\/td>\n.NET 11.0<\/td>\n3.741 ns<\/td>\n0.67<\/td>\n–<\/td>\n–<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
dotnet\/runtime#129410<\/a> from\n@MichalPetryka<\/a> follows up on the CoreCLR\nlayout by placing the target object and method pointer next to each other.\nThose are commonly consumed together during invocation, and the adjacency\nenables paired loads on architectures such as Arm64.<\/p>\n
Runtime Async<\/h3>\n
For more than a decade, async<\/code> and await<\/code> have let us write asynchronous code that looks remarkably similar to synchronous code: we can put a try<\/code>\/catch<\/code> around an await<\/code>, use local variables on either side of it, return a value and generally reason about the method in source order. When execution reaches an await<\/code> for something that isn’t yet complete, however, the method can’t simply leave its current stack frame in place and wait for the operation to finish. The thread needs to be freed up to do other work, while the work after the await<\/code>, including whatever local state it will need later, must survive somewhere. In C#, the compiler has traditionally been responsible for transforming the method into a representation that enables that continuation.<\/p>\n
I went into the history and mechanics of that transformation in How async\/await really works<\/a>. The very short version is that the compiler traditionally replaces an async<\/code> method with a small entry method and a generated state machine whose MoveNext<\/code> method contains the transformed user code. Parameters, locals that need to survive an incomplete await, spilled expression values, awaiters, the current state number, and a method builder all become fields on a heap-allocated object. The generated MoveNext<\/code> method runs the user’s code until an awaiter reports that it isn’t yet complete. It stores enough information to know where and with what values to resume, registers MoveNext<\/code> as the continuation, and returns. When the operation completes, MoveNext<\/code> is invoked again, jumps to the right location based on the saved state number (think goto<\/code> and a label), retrieves the result from a value-producing awaiter, and continues. If every awaiter is already complete, MoveNext<\/code> can run all the way through synchronously. When the method completes or throws, the builder publishes the result, cancellation, or exception through the returned Task<\/code>, Task<T><\/code>, ValueTask<\/code>, or ValueTask<T><\/code> (or, in the rare case, a custom task-like type).<\/p>\n
For example, consider this tiny method:<\/p>\n
static async Task<int> ReadLengthAsync(Stream stream, CancellationToken cancellationToken)\r\n{\r\n    var buffer = new byte[4096];\r\n    int bytesRead = await stream.ReadAsync(buffer, 0, buffer.Length, cancellationToken);\r\n    return bytesRead;\r\n}<\/code><\/pre>\n
While the code that gets generated for this changes over time and differs between debug and release builds, the lowering by the C# compiler has looked something like this:<\/p>\n
[AsyncStateMachine(typeof(<ReadLengthAsync>d__0))]\r\nstatic Task<int> ReadLengthAsync(Stream stream, CancellationToken cancellationToken)\r\n{\r\n    <ReadLengthAsync>d__0 stateMachine = default;\r\n    stateMachine.builder = AsyncTaskMethodBuilder<int>.Create();\r\n    stateMachine.state = -1;\r\n    stateMachine.stream = stream;\r\n    stateMachine.cancellationToken = cancellationToken;\r\n    stateMachine.builder.Start(ref stateMachine);\r\n    return stateMachine.builder.Task;\r\n}\r\n\r\nstruct <ReadLengthAsync>d__0 : IAsyncStateMachine\r\n{\r\n    public int state;\r\n    public AsyncTaskMethodBuilder<int> builder;\r\n    public Stream stream;\r\n    public CancellationToken cancellationToken;\r\n\r\n    private TaskAwaiter<int> awaiter;\r\n\r\n    public void MoveNext()\r\n    {\r\n        int result;\r\n        try\r\n        {\r\n            TaskAwaiter<int> localAwaiter;\r\n\r\n            if (state != 0)\r\n            {\r\n                byte[] buffer = new byte[4096];\r\n                localAwaiter = stream.ReadAsync(buffer, 0, buffer.Length, cancellationToken).GetAwaiter();\r\n                if (!localAwaiter.IsCompleted)\r\n                {\r\n                    state = 0;\r\n                    awaiter = localAwaiter;\r\n                    builder.AwaitUnsafeOnCompleted(ref localAwaiter, ref this);\r\n                    return;\r\n                }\r\n            }\r\n            else\r\n            {\r\n                localAwaiter = awaiter;\r\n                awaiter = default;\r\n                state = -1;\r\n            }\r\n\r\n            result = localAwaiter.GetResult();\r\n        }\r\n        catch (Exception e)\r\n        {\r\n            state = -2;\r\n            builder.SetException(e);\r\n            return;\r\n        }\r\n\r\n        state = -2;\r\n        builder.SetResult(result);\r\n    }\r\n}<\/code><\/pre>\n
That’s quite a lot of generated code for three lines of C#. The compiler has to make decisions before the program runs about the state-machine layout, which values might need to survive, how many awaiter fields are required, and how all the suspension points fit into one MoveNext<\/code> dispatch. The runtime and JIT have optimized the resulting pattern heavily over the years, including combining the task, state machine, continuation, and ExecutionContext<\/code> into a single allocation, but by the time the JIT sees the IL, the transformation has already happened, leaving it with a very complicated system to try to optimize.<\/p>\n
.NET 11 introduces a new way to split that responsibility, a reimplementation of the async<\/code>\/await<\/code> infrastructure referred to as “runtime async”. Rather than the C# compiler being responsible for the transformation, the JIT is. The C# compiler emits a much smaller suspension-aware IL contract for each eligible async<\/code> method and marks the method as async<\/code> in metadata. The runtime and JIT then do the work that depends on runtime knowledge: creating the externally visible Task<\/code> or ValueTask<\/code>, recognizing direct async calls, deciding which values are actually alive at each suspension point, laying out continuation objects, and generating the control flow that suspends and resumes the method. Effectively, the transformation moves from C# to the runtime, where more information is available to optimize it.<\/p>\n
The programming model hasn’t changed. This is still C# async<\/code>\/await<\/code>; await<\/code> still obeys the awaiter pattern, exceptions and cancellation still surface through the returned task-like object, ConfigureAwait<\/code> still has its usual meaning, synchronous completion is still synchronous completion, and on and on. An explicit goal for the feature has been 100% behavioral compatibility: whether an async<\/code> method is lowered by the language compiler or by the runtime is an implementation detail, and any observable semantic difference is a bug.<\/p>\n
In .NET 11, application code opts in with a compiler feature switch:<\/p>\n
<Project Sdk=\"Microsoft.NET.Sdk\">\r\n  <PropertyGroup>\r\n    <TargetFramework>net11.0<\/TargetFramework>\r\n    <Features>$(Features);runtime-async=on<\/Features>\r\n  <\/PropertyGroup>\r\n<\/Project><\/code><\/pre>\n
Note that there’s no new C# syntax involved, so LangVersion=preview<\/code> isn’t required, nor is EnablePreviewFeatures<\/code>. While this is opt-in at the application layer, most of the in-box shared framework is already built this way for .NET 11. The async<\/code>\/await<\/code> performance goal for .NET 11 is parity with .NET 10, and in general runtime async is already as good as or better than the older implementation in many important paths. It isn’t yet fully optimized, though, and there are known cases where it still produces less efficient code. I’d encourage you to experiment in .NET 11 with opting-in your applications and services; just make sure to measure. My hope is that it’ll be on by default starting in .NET 12.<\/p>\n
Moving the transformation from the C# compiler to the runtime has the added benefit of reducing binary size. As noted, the traditional lowering emits an entry method, a generated state-machine type, fields for captured state, and a MoveNext<\/code> body, for every async method. Runtime async leaves a much smaller method body for the runtime to transform. The following tiny app contains ten Task<int><\/code>-returning async methods, each awaiting the next, and compiles the same source once with compiler lowering and once with runtime async:<\/p>\n
<Project Sdk=\"Microsoft.NET.Sdk\">\r\n  <PropertyGroup>\r\n    <OutputType>Exe<\/OutputType>\r\n    <TargetFramework>net11.0<\/TargetFramework>\r\n    <AssemblyName>SizeProbe<\/AssemblyName>\r\n    <ImplicitUsings>enable<\/ImplicitUsings>\r\n    <Nullable>enable<\/Nullable>\r\n    <Features Condition=\"'$(RuntimeAsync)' == 'true'\">$(Features);runtime-async=on<\/Features>\r\n  <\/PropertyGroup>\r\n<\/Project><\/code><\/pre>\n
\/\/ dotnet build -c Release -p:RuntimeAsync=false -o classic --no-incremental; dotnet build -c Release -p:RuntimeAsync=true -o runtime --no-incremental; Get-Item .\\classic\\SizeProbe.dll, .\\runtime\\SizeProbe.dll | Select-Object Directory, Length\r\n\r\nConsole.WriteLine(await Benchmarks.Layer0());\r\n\r\npublic class Benchmarks\r\n{\r\n    public static async Task<int> Layer0() => await Layer1();\r\n    private static async Task<int> Layer1() => await Layer2();\r\n    private static async Task<int> Layer2() => await Layer3();\r\n    private static async Task<int> Layer3() => await Layer4();\r\n    private static async Task<int> Layer4() => await Layer5();\r\n    private static async Task<int> Layer5() => await Layer6();\r\n    private static async Task<int> Layer6() => await Layer7();\r\n    private static async Task<int> Layer7() => await Layer8();\r\n    private static async Task<int> Layer8() => await Layer9();\r\n\r\n    private static async Task<int> Layer9()\r\n    {\r\n        await Task.Yield();\r\n        return 42;\r\n    }\r\n}<\/code><\/pre>\n\n\n\n\n\n\n
Lowering<\/th>\nSizeProbe.dll<\/th>\nRatio<\/th>\n<\/tr>\n<\/thead>\n
Compiler<\/td>\n10,752 bytes<\/td>\n1.00<\/td>\n<\/tr>\n
Runtime async<\/td>\n5,632 bytes<\/td>\n0.52<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
For a method such as:<\/p>\n
static async Task<int> CallerAsync() => await CalleeAsync();<\/code><\/pre>\n
with runtime async enabled, the C# compiler generates IL like the following:<\/p>\n
; MSIL\r\n.method private hidebysig static\r\n    class System.Threading.Tasks.Task`1<int32> CallerAsync() cil managed async\r\n{\r\n    call class System.Threading.Tasks.Task`1<int32> CalleeAsync()\r\n    call int32 System.Runtime.CompilerServices.AsyncHelpers::Await<int32>(\r\n        class System.Threading.Tasks.Task`1<int32>)\r\n    ret\r\n}<\/code><\/pre>\n
There is no generated <CallerAsync>d__0<\/code> type, no IAsyncStateMachine<\/code>, no MoveNext<\/code>, no AsyncTaskMethodBuilder<int><\/code>, and no AsyncStateMachineAttribute<\/code>. Previously, async<\/code> on a C# method evaporated at compile time. Now, the method has a new MethodImpl<\/code> async<\/code> bit, represented in IL assembly syntax by that async<\/code> modifier, and the body calls helpers in System.Runtime.CompilerServices.AsyncHelpers<\/code>.<\/p>\n
At first glance the ret<\/code> looks impossible because the declared signature returns Task<int><\/code> while the value on the IL evaluation stack is an int<\/code>. This clearly isn’t a normal calling convention. The VM can give a Task<\/code>-returning method two related identities, or MethodDescs, where one has the normal signature the rest of managed code sees, Task<int> CallerAsync()<\/code>. The other is the AsyncCall variant, which effectively returns int<\/code> and has an implicit channel for a continuation. Both refer to the same logical method and metadata token, but they have different calling conventions and different jobs. If regular managed code invokes CallerAsync<\/code>, the VM-generated outer thunk preserves the public contract and returns a Task<int><\/code>. If another runtime async method directly awaits it, the JIT can instead call the AsyncCall variant and receive the result directly when the call completes synchronously, or a continuation when it suspends. In other words, it can hand back the T<\/code> directly and avoid allocating a Task<T><\/code>.<\/p>\n
That pairing works in both directions. For a method compiled with runtime async, the AsyncCall variant owns the generated (newly compact) IL while the public Task<\/code>-returning entry point is an adapter thunk; for a traditionally compiled method, the public method owns its usual IL while the VM can create an AsyncCall adapter around it. That means runtime async code remains able to await existing libraries and code compiled by older compilers, a critical capability for our goal of 100% compat. The largest wins naturally appear as more of an async call chain is compiled with runtime async.<\/p>\n
This is where the JIT gets an opportunity that simply didn’t exist when every boundary was already expressed as a task and a generated state machine. Suppose A<\/code> awaits B<\/code>, which awaits C<\/code>:<\/p>\n
static async Task<int> A(bool yield) => await B(yield);\r\nstatic async Task<int> B(bool yield) => await C(yield);\r\nstatic async Task<int> C(bool yield)\r\n{\r\n    if (yield)\r\n        await Task.Yield();\r\n\r\n    return 42;\r\n}<\/code><\/pre>\n
Traditionally, each method has its own compiler-generated state machine and its own task-like result. C<\/code> suspends and eventually completes its task, which wakes B<\/code>‘s state machine; B<\/code> then completes its task, which wakes A<\/code>‘s state machine; and A<\/code> completes the root task observed by the caller. There has been an enormous amount of work done over the years to reduce the costs of those objects and transitions.<\/p>\n
With runtime async, the importer recognizes the adjacent pattern of “call a Task-returning method, then await that task.” In the simple case it can call the callee’s AsyncCall variant instead. When yield<\/code> is false and C<\/code> completes synchronously, the int<\/code> flows back through B<\/code> and A<\/code> as a plain value, and only the outermost boundary needs to turn it into the Task<int><\/code> promised to the original caller. When yield<\/code> is true and C<\/code> suspends, the runtime links continuation state for the chain and eventually resumes it without requiring an intermediate Task<int><\/code> at every directly fused edge. The Task<\/code> contract hasn’t vanished, it just moved to the place where a Task<\/code> is actually needed.<\/p>\n
Runtime async doesn’t make every asynchronous operation allocation-free, though. Rather, it gives the JIT enough information to avoid materializing some task objects that existed only to carry a result from one async method directly into the next. If a consumer stores the task in a collection, manually hooks up a continuation, or otherwise observes the task as an object, that object is still needed. The optimization is about not paying for boundaries that aren’t observably boundaries.<\/p>\n
The impact is already visible with just two layers:<\/p>\n
\/\/ dotnet run -c Release -f net11.0 --filter \"*\"\r\n\/\/ The project also needs the `runtime-async=on` feature switch set.\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Configs;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[MemoryDiagnoser(false)]\r\n[GroupBenchmarksBy(BenchmarkLogicalGroupRule.ByCategory)]\r\n[HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private static readonly Task<int> s_completed = Task.FromResult(42);\r\n\r\n    [Benchmark(Baseline = true), BenchmarkCategory(\"Completed\")]\r\n    public Task<int> ClassicCompleted() => ClassicCompletedOuter();\r\n\r\n    [Benchmark, BenchmarkCategory(\"Completed\")]\r\n    public Task<int> RuntimeCompleted() => RuntimeCompletedOuter();\r\n\r\n    [Benchmark(Baseline = true), BenchmarkCategory(\"Yielding\")]\r\n    public Task<int> ClassicYielding() => ClassicYieldingOuter();\r\n\r\n    [Benchmark, BenchmarkCategory(\"Yielding\")]\r\n    public Task<int> RuntimeYielding() => RuntimeYieldingOuter();\r\n\r\n    [RuntimeAsyncMethodGeneration(false)]\r\n    private static async Task<int> ClassicCompletedOuter() => await ClassicCompletedInner();\r\n\r\n    [RuntimeAsyncMethodGeneration(false)]\r\n    private static async Task<int> ClassicCompletedInner() => await s_completed;\r\n\r\n    private static async Task<int> RuntimeCompletedOuter() => await RuntimeCompletedInner();\r\n\r\n    private static async Task<int> RuntimeCompletedInner() => await s_completed;\r\n\r\n    [RuntimeAsyncMethodGeneration(false)]\r\n    private static async Task<int> ClassicYieldingOuter() => await ClassicYieldingInner();\r\n\r\n    [RuntimeAsyncMethodGeneration(false)]\r\n    private static async Task<int> ClassicYieldingInner()\r\n    {\r\n        await Task.Yield();\r\n        return 42;\r\n    }\r\n\r\n    private static async Task<int> RuntimeYieldingOuter() => await RuntimeYieldingInner();\r\n\r\n    private static async Task<int> RuntimeYieldingInner()\r\n    {\r\n        await Task.Yield();\r\n        return 42;\r\n    }\r\n}\r\n\r\nnamespace System.Runtime.CompilerServices\r\n{\r\n    [AttributeUsage(AttributeTargets.Method)]\r\n    internal sealed class RuntimeAsyncMethodGenerationAttribute(bool runtimeAsync) : Attribute\r\n    {\r\n        public bool RuntimeAsync => runtimeAsync;\r\n    }\r\n}<\/code><\/pre>\n\n\n\n\n\n\n\n\n
Method<\/th>\nMean<\/th>\nRatio<\/th>\nAllocated<\/th>\nAlloc Ratio<\/th>\n<\/tr>\n<\/thead>\n
ClassicCompleted<\/td>\n21.221 ns<\/td>\n1.00<\/td>\n144 B<\/td>\n1.00<\/td>\n<\/tr>\n
RuntimeCompleted<\/td>\n6.151 ns<\/td>\n0.29<\/td>\n0 B<\/td>\n0.00<\/td>\n<\/tr>\n
ClassicYielding<\/td>\n254.139 ns<\/td>\n1.00<\/td>\n248 B<\/td>\n1.00<\/td>\n<\/tr>\n
RuntimeYielding<\/td>\n116.927 ns<\/td>\n0.46<\/td>\n168 B<\/td>\n0.68<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The synchronously completing chain is more than 3x faster and avoids both\nintermediate task allocations. Even after a real suspension, the same\ntwo-layer chain takes less than half the time and allocates 80 fewer bytes.<\/p>\n
Exception handling amplifies the difference. Again consider an async method A<\/code> calling an async method B<\/code> calling an async method C<\/code>. The transformation generated by the C# compiler of each method results in a try<\/code>\/catch<\/code> block around the whole body of the MoveNext<\/code> method so that any unhandled exception can be stored into the returned Task<\/code>. Let’s say code in C<\/code> throws an unhandled exception. That’s then caught by this manufactured catch<\/code> block and stored into the Task<\/code> returned to B<\/code>. The awaiter in B<\/code> then retrieves that exception from the Task<\/code> object and throws it. It’s then caught by B<\/code>‘s generated catch and stored into its Task<\/code>. And so on. An exception crossing ten such async helpers can therefore be thrown, caught, and stored ten times even though none of the source methods has an explicit handler. That is super expensive. But runtime async doesn’t need to re-enter a pass-through frame with no handler. On the synchronous path the exception unwinds through the fused calls normally, and after a real suspension, one dispatch-loop catch walks past continuation records that have no handler and faults the observable root task once.<\/p>\n
The following benchmark measures both a fully synchronous throw and an exception after one real Task.Yield<\/code> suspension. It uses a compiler-recognized per-method escape hatch (RuntimeAsyncMethodGeneration<\/code>) so that the classic and runtime async methods run in the same process on the same .NET 11 runtime and differ only in how the compiler lowers them. (Note that this attribute is experimental and isn’t a public API exposed from the core libraries; as with other attributes known to the C# compiler, it recognizes them by name and signature.)<\/p>\n
\/\/ dotnet run -c Release -f net11.0 --filter \"*\"\r\n\/\/ The project also needs the `runtime-async=on` feature switch set.\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[MemoryDiagnoser(false), HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    [Params(1, 10, 30)]\r\n    public int Depth;\r\n\r\n    [Params(false, true)]\r\n    public bool Yield;\r\n\r\n    [Benchmark(Baseline = true)]\r\n    public int Classic() => Invoke(ClassicThrowAsync(Depth));\r\n\r\n    [Benchmark]\r\n    public int Runtime() => Invoke(RuntimeThrowAsync(Depth));\r\n\r\n    private static int Invoke(Task<int> task)\r\n    {\r\n        try\r\n        {\r\n            return task.GetAwaiter().GetResult();\r\n        }\r\n        catch (InvalidOperationException)\r\n        {\r\n            return -1;\r\n        }\r\n    }\r\n\r\n    [RuntimeAsyncMethodGeneration(false)]\r\n    private async Task<int> ClassicThrowAsync(int depth)\r\n    {\r\n        if (depth == 0)\r\n        {\r\n            if (Yield) await Task.Yield();\r\n            throw new InvalidOperationException(\"uh oh\");\r\n        }\r\n\r\n        return await ClassicThrowAsync(depth - 1);\r\n    }\r\n\r\n    private async Task<int> RuntimeThrowAsync(int depth)\r\n    {\r\n        if (depth == 0)\r\n        {\r\n            if (Yield) await Task.Yield();\r\n            throw new InvalidOperationException(\"uh oh\");\r\n        }\r\n\r\n        return await RuntimeThrowAsync(depth - 1);\r\n    }\r\n}\r\n\r\nnamespace System.Runtime.CompilerServices\r\n{\r\n    [AttributeUsage(AttributeTargets.Method)]\r\n    internal sealed class RuntimeAsyncMethodGenerationAttribute(bool runtimeAsync) : Attribute\r\n    {\r\n        public bool RuntimeAsync => runtimeAsync;\r\n    }\r\n}<\/code><\/pre>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Depth<\/th>\nYield<\/th>\nMethod<\/th>\nMean<\/th>\nRatio<\/th>\nAllocated<\/th>\nAlloc Ratio<\/th>\n<\/tr>\n<\/thead>\n
1<\/td>\nFalse<\/td>\nClassic<\/td>\n4.727 \u03bcs<\/td>\n1.00<\/td>\n1.6 KB<\/td>\n1.00<\/td>\n<\/tr>\n
1<\/td>\nFalse<\/td>\nRuntime<\/td>\n3.558 \u03bcs<\/td>\n0.75<\/td>\n1.16 KB<\/td>\n0.72<\/td>\n<\/tr>\n
1<\/td>\nTrue<\/td>\nClassic<\/td>\n6.308 \u03bcs<\/td>\n1.00<\/td>\n1.68 KB<\/td>\n1.00<\/td>\n<\/tr>\n
1<\/td>\nTrue<\/td>\nRuntime<\/td>\n8.211 \u03bcs<\/td>\n1.30<\/td>\n1.42 KB<\/td>\n0.85<\/td>\n<\/tr>\n
10<\/td>\nFalse<\/td>\nClassic<\/td>\n19.469 \u03bcs<\/td>\n1.00<\/td>\n15.13 KB<\/td>\n1.00<\/td>\n<\/tr>\n
10<\/td>\nFalse<\/td>\nRuntime<\/td>\n5.885 \u03bcs<\/td>\n0.30<\/td>\n2.13 KB<\/td>\n0.14<\/td>\n<\/tr>\n
10<\/td>\nTrue<\/td>\nClassic<\/td>\n24.923 \u03bcs<\/td>\n1.00<\/td>\n15.63 KB<\/td>\n1.00<\/td>\n<\/tr>\n
10<\/td>\nTrue<\/td>\nRuntime<\/td>\n6.122 \u03bcs<\/td>\n0.25<\/td>\n2.88 KB<\/td>\n0.18<\/td>\n<\/tr>\n
30<\/td>\nFalse<\/td>\nClassic<\/td>\n51.302 \u03bcs<\/td>\n1.00<\/td>\n84.2 KB<\/td>\n1.00<\/td>\n<\/tr>\n
30<\/td>\nFalse<\/td>\nRuntime<\/td>\n10.721 \u03bcs<\/td>\n0.21<\/td>\n5.71 KB<\/td>\n0.07<\/td>\n<\/tr>\n
30<\/td>\nTrue<\/td>\nClassic<\/td>\n65.974 \u03bcs<\/td>\n1.00<\/td>\n85.53 KB<\/td>\n1.00<\/td>\n<\/tr>\n
30<\/td>\nTrue<\/td>\nRuntime<\/td>\n11.254 \u03bcs<\/td>\n0.17<\/td>\n7.72 KB<\/td>\n0.09<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Runtime async supports Task<\/code>, Task<T><\/code>, ValueTask<\/code>, and ValueTask<T><\/code> as method return types, but as of today it doesn’t support async void<\/code>, async iterators, or arbitrary custom task-like return types with custom builders; those continue to use the traditional compiler transformation. For ValueTask<T><\/code>, the existing reasons to use the type still apply. A ValueTask<T><\/code> can carry a result directly, wrap a Task<T><\/code>, or refer to an IValueTaskSource<T><\/code>. That’s made it useful for APIs where synchronous completion is common enough that avoiding a Task<\/code> allocation outweighs the larger return value and the more restrictive consumption rules, or where asynchronous completion can have its costs amortized via a reusable backing object. Runtime async then addresses some of the scenarios that would have led developers to use ValueTask<T><\/code>. Does that mean everyone should stop using ValueTask<T><\/code>? No. Choosing Task<\/code> versus ValueTask<\/code> remains an API design decision based on completion patterns, allocation sensitivity, call frequency, and how consumers need to use the result. Write the return type that makes sense for the API, then let the compiler, VM, and JIT optimize it as best they can.<\/p>\n
Workloads with many layers of small async methods can benefit the most from runtime\nasync, because those layers are exactly where intermediate tasks and state\nmachines often accumulate. Shared framework code, for example, is full of this\npattern: a public method validates arguments and awaits a private helper, which\nawaits a transport helper, which awaits an operating-system operation.\nApplication services similarly compose authentication, retry, logging,\nserialization, and I\/O helpers. Runtime async can make the source-level\ndecomposition cheaper without asking the developer to flatten the code into\none giant method in order to avoid “implementation detail” costs.<\/p>\n
The work required to reach this point has been extensive. A GitHub search of the runtime async tracking label<\/a> on September 14, 2026 returned 235 pull requests, far too many for me to enumerate one by one. So I won’t try; you can peruse that label in your spare time. The work is also not only about direct performance improvements but also about\nimprovements to diagnostics and performance tooling that help you to make better\nuse of async in your own code. When an async method\nsuspends, its physical thread stack unwinds. That method’s continuation might later run\non a different thread whose physical stack begins in the thread pool, with the\nmethods that led to the original await<\/code> nowhere to be found. A sampling\nCPU profiler can see where the processor is spending time, but without additional\ninformation, it can’t reliably connect those traces back through the logical async\ncall chain, making it hard to answer questions about what async call paths were actually costing.\nProfiling tools like the async profiler in Visual Studio have traditionally reconstructed those chains from\nevents emitted by Task<\/code>‘s infrastructure, but async-heavy applications can generate enormous volumes of\nthose very chatty events. The resulting overhead easily perturbs the workload being measured, making\nit all but unusable in production. dotnet\/runtime#127238<\/a> added a\nnew lightweight async-profiler event stream for .NET 11 and runtime async. Rather than sending every small\ntransition through the eventing system as its own full event, the runtime\nwrites compact records into per-thread buffers, delta-encoding timestamps and\ninstruction pointers and flushing the data in batches. It also puts a small\nidentifiable wrapper frame into the physical stack when invoking a\ncontinuation. A profiler can use that frame as an anchor, joining ordinary CPU\nsamples to the logical async call stack represented by the event stream. In some measurements,\nthis new approach added less than 1% overhead and shrank the traced data by an order of magnitude.\ndotnet\/runtime#129043<\/a> and a few follow-up PRs extended\nthe same approach to the compiler-generated state machines used by existing\nasync code. Thus this\nisn’t useful only to applications that opt into runtime async; tooling gets one\nconsistent representation across both implementations.<\/p>\n
What should you as a developer do differently with runtime async in the picture? Mostly nothing. Keep writing asynchronous code the way you want it to read, and break a large operation into helpers when that makes the code clearer. Use Task<\/code> by default and choose ValueTask<\/code> where its API and usage tradeoffs genuinely fit. And don’t contort source code to remove a clean await<\/code> just because today’s implementation might allocate an intermediate Task<\/code>. The lowering strategy should “just work” as an implementation detail, preserve behavior, and make existing source get better as the runtime improves.<\/p>\n
Bounds Checks<\/h3>\n
C# is a memory-safe language. Accesses to arrays, strings, and spans are guaranteed by the runtime to be in-bounds; if you try to access someArray[i]<\/code>, someString[i]<\/code>, or someSpan[i]<\/code> with an index less than 0 or greater than or equal to the length of the array\/string\/span, you’ll get an exception, not silently corrupted memory or a process crash. The runtime guarantees that all permitted accesses are within bounds, and that means it needs to be able to prove the access is in bounds. The main method the JIT has for achieving that is by injecting code that performs a bounds check, as if instead of:<\/p>\n
int[] array = ...;\r\nint value = array[i];<\/code><\/pre>\n
you’d written:<\/p>\n
int[] array = ...;\r\nif ((uint)i >= array.Length) throw new IndexOutOfRangeException();\r\nint value = array[i];<\/code><\/pre>\n
At the assembly level, a bounds check looks something like:<\/p>\n
; x64\r\ncmp ecx, dword ptr [rax+8]        ; compare index with array length\r\njae THROW                         ; unsigned index >= length\r\nmov edx, dword ptr [rax+rcx*4+16] ; load the element<\/code><\/pre>\n
The JIT could just inject such code on every access and call it a day, but such code adds overhead, so the JIT works to elide those checks and that overhead wherever it can prove the index is valid. Proving an index is valid means the JIT needs to be able to see from other evidence that it couldn’t possibly be out of bounds.<\/p>\n
The quintessential example of that is a for<\/code> loop over the full contents of an array or span:<\/p>\n
for (int i = 0; i < array.Length; i++)\r\n{\r\n    Use(array[i]);\r\n}<\/code><\/pre>\n
The JIT recognizes from this idiom that, within the loop body, i<\/code> is guaranteed to be in the range [0, array.Length)<\/code>, and avoids emitting the bounds check for the array[i]<\/code> access. The JIT has long handled this particular case. Other cases, not so much. Bounds-check elimination has improved in virtually every .NET release; more recent releases added range propagation for derived expressions (.NET 7<\/code> and .NET 8<\/code> saw significant improvements here), SSA-based reasoning (.NET 9<\/code>), and better handling of Span<T><\/code>, whose length sits in a field rather than an object header, complicating tracking. Each year, the developers contributing to the JIT find new patterns that were being missed, that show up in the wild, and that are fixable. .NET 11 improves several such patterns.<\/p>\n
Range analysis in the JIT tracks intervals for each variable, an upper bound and a lower bound. For example, taking the true branch of x < 5<\/code> gives the range for x<\/code> in that branch an upper bound of 4 while taking the true branch of x > 2<\/code> makes the lower bound 3. What about x != 5<\/code>? On the true edge, we know x<\/code> isn’t 5, and if the current range for x<\/code> is [5, 10]<\/code>, then we know the range must actually be [6, 10]<\/code>… the lower bound can be tightened because the only value at the lower end is excluded. Similarly, if the range is [0, 5]<\/code>, an x != 5<\/code> assertion tells us the range is actually the narrower [0, 4]<\/code>. Or, at least, that’s what you’d hope it would do. The JIT had this relevant comment:<\/p>\n
\/\/ We have a != assertion, but it doesn't tell us much about the interval. So just skip it.\r\ncontinue;<\/code><\/pre>\n
In .NET 11, dotnet\/runtime#121273<\/a> replaces that logic with productive reasoning. It checks whether the excluded constant is at either edge of the currently tracked range, adding in the new insights if so. C# list patterns, introduced in C# 11, generate just such comparison sequences. For example, the pattern name is [] or [':'] or [':', not ':', ..]<\/code> lowers to something like this:<\/p>\n
if (name != null)\r\n{\r\n    int num = name.Length;\r\n\r\n    if (num == 0) return true;\r\n\r\n    if (num == 1)\r\n    {\r\n        if (name[0] == ':') return true;\r\n    }\r\n    else if (name[0] == ':' && name[1] != ':')\r\n    {\r\n        return true;\r\n    }\r\n\r\n    return false;\r\n}<\/code><\/pre>\n
Range analysis then proceeds with something like this:<\/p>\n
    \n
  1. We know that Array.Length<\/code> is never negative, so it has a range of [0, Array.MaxLength]<\/code>.<\/li>\n
  2. On the false edge of num == 0<\/code>, we know that num != 0<\/code>, so the range is narrowed now to [1, Array.MaxLength]<\/code>.<\/li>\n
  3. Similarly, on the false edge of num == 1<\/code>, we know that num != 1<\/code>, so the range is narrowed now to [2, Array.MaxLength]<\/code>.<\/li>\n
  4. We then access name[0]<\/code> and name[1]<\/code>, both of which are guaranteed in bounds based on the lower bound of 2 that was established.<\/li>\n<\/ol>\n
    Without the != constant<\/code> tightening, that narrowing wouldn’t happen, and the bounds checks in step 4 couldn’t be elided. Thankfully, they now can be in .NET 11. Consider this example:<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[DisassemblyDiagnoser, HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private string[] _inputs = [\"\", \":\", \":x\", \"abc\", \":ab\", \"x\", \"ab:cd\"];\r\n\r\n    [Benchmark]\r\n    public int ClassifyAll()\r\n    {\r\n        int total = 0;\r\n        foreach (string s in _inputs) total += Classify(s);\r\n        return total;\r\n    }\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static int Classify(ReadOnlySpan<char> name) =>\r\n        name switch\r\n        {\r\n            [] => 0,\r\n            [':'] => 1,\r\n            [':', not ':', ..] => 10 + name[0] + name[1],\r\n            _ => 3\r\n        };\r\n}<\/code><\/pre>\n
    In .NET 10, we can see the call to CORINFO_HELP_RNGCHKFAIL<\/code> at the bottom of the method. That’s the tell-tale sign there was at least one bounds check in the method. With .NET 11, that sign is removed.<\/p>\n
    ; Arm64\r\n--- .NET 10\r\n+++ .NET 11\r\n@@ -10,17 +10,15 @@\r\n             beq     G_M000_IG08\r\n\r\n G_M000_IG04:\r\n-            ldrh    w2, [x0]\r\n-            cmp     w2, #58\r\n+            ldrh    w1, [x0]\r\n+            cmp     w1, #58\r\n             bne     G_M000_IG06\r\n\r\n G_M000_IG05:\r\n-            cmp     w1, #1\r\n-            bls     G_M000_IG11\r\n             ldrh    w0, [x0, #0x02]\r\n             cmp     w0, #58\r\n             beq     G_M000_IG06\r\n-            add     w0, w2, w0\r\n+            add     w0, w1, w0\r\n             add     w0, w0, #10\r\n             b       G_M000_IG07\r\n\r\n@@ -44,8 +42,4 @@\r\n             mov     w0, wzr\r\n             b       G_M000_IG07\r\n\r\n-G_M000_IG11:\r\n-            bl      CORINFO_HELP_RNGCHKFAIL\r\n-            brk     #0\r\n-\r\n-; Total bytes of code 112\r\n+; Total bytes of code 96<\/code><\/pre>\n
    “Assertion” machinery in the JIT propagates learned facts (like the aforementioned range information) between “basic blocks” (a sequence of instructions with one entry point, one exit point, and no branches into or out of the middle of it), so information established in block A flows to block B if A “dominates” B (meaning the only way to get to B is through A). But what about facts established earlier within the same block? That’s the gap that dotnet\/runtime#121527<\/a> addresses. Consider this code:<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[DisassemblyDiagnoser, HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private int[] _arr = new int[512];\r\n\r\n    [Benchmark]\r\n    public int RunMany()\r\n    {\r\n        int touched = 0;\r\n        for (int i = 0; i < _arr.Length - 2; i++)\r\n        {\r\n            Test(_arr, i);\r\n            touched++;\r\n        }\r\n        return touched;\r\n    }\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static void Test(int[] arr, int i)\r\n    {\r\n        arr[i] = 0;  \/\/ 1: establishes 'i >= 0 && i < arr.Length'\r\n        i++;         \/\/ 2: same block\r\n        if (i < arr.Length) arr[i] = 0;  \/\/ 3: proven safe from 1's assertion\r\n    }\r\n}<\/code><\/pre>\n
    Statements 1, 2, and 3 are all in the same basic block, up to the conditional; after statement 1 executes, if we reach statement 2, the bounds check on statement 1 passed, we know i >= 0<\/code> and i < arr.Length<\/code>, and after statement 2, i<\/code> becomes i + 1<\/code>. After the if<\/code> guard i < arr.Length<\/code> we know the incremented i<\/code> is still within bounds. But when the range check pass in the .NET 10 JIT examined statement 3’s bounds check, it saw the assertions propagated from predecessor blocks. Since the assertion from statement 1 is generated within the current block, the range check couldn’t see it. The PR fixed it to walk the current block’s tree in execution order, accumulating assertions as it went. When we reach statement 3’s bounds check, we’ve already walked past statement 1 and picked up its i >= 0 && i < arr.Length<\/code> assertion.<\/p>\n
    ; Arm64\r\n--- .NET 10\r\n+++ .NET 11\r\n@@ -13,8 +13,6 @@\r\n             ble     G_M000_IG04\r\n\r\n G_M000_IG03:\r\n-            cmp     w1, w2\r\n-            bhs     G_M000_IG05\r\n             str     wzr, [x0, w1, UXTW #2]\r\n\r\n G_M000_IG04:\r\n@@ -25,4 +23,4 @@\r\n             bl      CORINFO_HELP_RNGCHKFAIL\r\n             brk     #0\r\n\r\n-; Total bytes of code 68\r\n+; Total bytes of code 60<\/code><\/pre>\n
    There are almost an infinite number of things the JIT could look for and special-case. But every special case requires code, maintenance, and, most importantly, compilation time. A “just-in-time” compiler typically runs while the application is running, so the JIT itself must be optimized and spend its limited budget only where there’s a likely payoff. That pushes the developers building it toward patterns that occur in real workloads. One such pattern, often seen in libraries like format decoders, builds a table\nindex with bitwise operations on a byte, for example\n((b & 0x03) << 4) | ((b & 0xf0) >> 4)<\/code>. Each masked piece has a tiny upper\nbound, so the OR of those pieces is always in [0..63]<\/code>, safely in range for\ne.g. a Base64 alphabet table. Until\ndotnet\/runtime#122263<\/a>, the JIT\noften failed to prove that combined bound and left a bounds check on the\nindex. Existing range-check code understood the upper bounds produced by\nbitwise AND and shifts, but not OR; the change lets the JIT combine the known\nbounds of both OR operands and remove the remaining array check.<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[DisassemblyDiagnoser, HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private readonly byte[] _input = new byte[4096];\r\n\r\n    [GlobalSetup]\r\n    public void Setup() => new Random(42).NextBytes(_input);\r\n\r\n    [Benchmark]\r\n    public int Base64LikeIndex() => Sum(_input);\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static int Sum(ReadOnlySpan<byte> input)\r\n    {\r\n        int sum = 0;\r\n        foreach (byte b in input)\r\n        {\r\n            int index = ((b & 0x03) << 4) | ((b & 0xF0) >> 4);\r\n            sum += \"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+\/=\"u8[index];\r\n        }\r\n\r\n        return sum;\r\n    }\r\n}<\/code><\/pre>\n
    The .NET 10 assembly checks the computed index against the 65-byte lookup\ntable on every iteration. In .NET 11, range analysis proves the index is at\nmost 63, so both the comparison and the branch to the range-check failure\nhelper disappear:<\/p>\n
    ; x64\r\n M01_L00:\r\n        movzx    r9d, byte ptr [rdx+r8]\r\n        mov      r11d, r9d\r\n        and      r11d, 3\r\n        shl      r11d, 4\r\n        and      r9d, 0F0\r\n        sar      r9d, 4\r\n        or       r9d, r11d\r\n-       cmp      r9d, 41\r\n-       jae      short M01_L02\r\n        movzx    r9d, byte ptr [r10+r9]\r\n        add      eax, r9d\r\n        inc      r8d\r\n        cmp      r8d, ecx\r\n        jl       short M01_L00\r\n\r\n-M01_L02:\r\n-       call     CORINFO_HELP_RNGCHKFAIL\r\n-       int      3\r\n-\r\n-; Total bytes of code 95\r\n+; Total bytes of code 79<\/code><\/pre>\n
    As another example, dotnet\/runtime#125056<\/a> improves the handling of guards like (uint)i < span.Length<\/code> that are pervasive in performance-sensitive code. Consider this benchmark:<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[DisassemblyDiagnoser, HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private int[] _data = Enumerable.Range(0, 512).ToArray();\r\n\r\n    [Benchmark]\r\n    public int RunMany()\r\n    {\r\n        int sum = 0;\r\n        for (int i = 0; i < _data.Length; i++)\r\n            sum += Test(_data, i);\r\n        return sum;\r\n    }\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static int Test(Span<int> span, int i)\r\n    {\r\n        if ((uint)i < (uint)span.Length)\r\n        {\r\n            if (i != 0)\r\n                return span[i - 1] + span[i];\r\n\r\n            return span[i];\r\n        }\r\n\r\n        return 0;\r\n    }\r\n}<\/code><\/pre>\n
    Because the comparison is unsigned, (uint)i<\/code> would be a large positive number if i<\/code> were negative, making it impossible for (uint)i < (uint)span.Length<\/code> to be true (since a span’s length is never negative, (uint)span.Length<\/code> is at most int.MaxValue<\/code>). Inside the true branch, i<\/code> is therefore in [0, span.Length - 1]<\/code>. Previously, the JIT wasn’t always recording the lower bound i >= 0<\/code> when it processed the (uint)i < span.Length<\/code> assertion, and that could leave bounds checks on expressions like i - 1<\/code> in place. The fix adds the [0, int.MaxValue - 1]<\/code> lower bound deduction for the index variable upon entering the true arm of a (uint)i < span.Length<\/code> check. Combined with the existing range tracking for the upper bound, this gives the JIT a complete picture of i<\/code>‘s range inside the guarded block.<\/p>\n
    ; Arm64\r\n--- .NET 10\r\n+++ .NET 11\r\n@@ -8,10 +8,8 @@\r\n             cbz     w2, G_M000_IG05\r\n\r\n G_M000_IG03:\r\n-            sub     w3, w2, #1\r\n-            cmp     w3, w1\r\n-            bhs     G_M000_IG09\r\n-            ldr     w1, [x0, w3, UXTW #2]\r\n+            sub     w1, w2, #1\r\n+            ldr     w1, [x0, w1, UXTW #2]\r\n             ldr     w0, [x0, w2, UXTW #2]\r\n             add     w0, w1, w0\r\n\r\n@@ -33,8 +31,4 @@\r\n             ldp     fp, lr, [sp], #0x10\r\n             ret     lr\r\n\r\n-G_M000_IG09:\r\n-            bl      CORINFO_HELP_RNGCHKFAIL\r\n-            brk     #0\r\n-\r\n-; Total bytes of code 84\r\n+; Total bytes of code 68<\/code><\/pre>\n
    Bounds check elision is generally based on forms of range analysis, where the JIT needs to prove that a given index is guaranteed to be within the range of the data structure. But the same range analysis-based facts can prove that other checks are unnecessary. For example, once the JIT knows that an integer is in [0..100]<\/code>, it can prove both that converting it to byte<\/code> can’t lose data and that multiplying it by 10 can’t overflow. dotnet\/runtime#124147<\/a> enables the JIT to use such facts to avoid unnecessary branches as part of checked<\/code> operations. When range analysis proves that the operands are in ranges whose result can’t overflow, making checked<\/code> a nop, the backend can now emit plain add\/multiply\/subtract instructions, without the jump to failure, as in the following example:<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[DisassemblyDiagnoser, HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private readonly int[] _array = new int[99];\r\n\r\n    [Benchmark]\r\n    public int ArrayLengthPlusConstant() => AddToLength(_array);\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static int AddToLength(int[] array) => checked(array.Length + 10);\r\n\r\n    [Benchmark]\r\n    public int GuardedLengthTimesConstant() => Multiply(_array);\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static int Multiply(Span<int> span)\r\n    {\r\n        if (span.Length >= 100) return 0;\r\n        return checked(span.Length * 10);\r\n    }\r\n}<\/code><\/pre>\n
    ; Arm64\r\n--- .NET 10\r\n+++ .NET 11\r\n G_M000_IG02:\r\n             cmp     w1, #100\r\n             bge     G_M000_IG05\r\n\r\n G_M000_IG03:\r\n             mov     w0, #10\r\n-            smull   x0, w1, w0\r\n-            lsr     x2, x0, #32\r\n-            cmp     w2, w0, ASR #31\r\n+            mul     w0, w1, w0\r\n-            bne     G_M000_IG07\r\n\r\n G_M000_IG04:\r\n             ldp     fp, lr, [sp], #0x10\r\n             ret     lr\r\n\r\n-G_M000_IG07:\r\n-            bl      CORINFO_HELP_OVERFLOW\r\n-            brk     #0\r\n-\r\n-; Total bytes of code 64\r\n+; Total bytes of code 44<\/code><\/pre>\n
    That makes the change broadly applicable: any time you write checked<\/code> arithmetic on quantities that are inherently bounded, such as collection counts, lengths, or indices constrained by prior comparisons, the JIT now has a chance to prove at compile time that the overflow can’t happen and thus eliminate the run-time check entirely. Building on that range-check work, dotnet\/runtime#124184<\/a> teaches the JIT to eliminate “narrowing casts” under the same kinds of guards:<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[DisassemblyDiagnoser, HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private uint _value = 100;\r\n\r\n    [Benchmark]\r\n    public byte GuardedNarrowingCast() => Narrow(_value);\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static byte Narrow(uint value)\r\n    {\r\n        if (value > 100) return 0;\r\n        return checked((byte)value);\r\n    }\r\n}<\/code><\/pre>\n
    ; Arm64\r\n--- .NET 10\r\n+++ .NET 11\r\n@@ -4,23 +4,10 @@\r\n\r\n G_M000_IG02:\r\n             cmp     w0, #100\r\n-            bhi     G_M000_IG04\r\n-            cmp     w0, #255\r\n-            bhi     G_M000_IG06\r\n+            csel    w0, w0, wzr, ls\r\n\r\n G_M000_IG03:\r\n             ldp     fp, lr, [sp], #0x10\r\n             ret     lr\r\n\r\n-G_M000_IG04:\r\n-            mov     w0, wzr\r\n-\r\n-G_M000_IG05:\r\n-            ldp     fp, lr, [sp], #0x10\r\n-            ret     lr\r\n-\r\n-G_M000_IG06:\r\n-            bl      CORINFO_HELP_OVERFLOW\r\n-            brk     #0\r\n-\r\n-; Total bytes of code 52\r\n+; Total bytes of code 24<\/code><\/pre>\n
    Such use of checked<\/code> is common in serialization and protocol code where you validate a value’s range prior to truncating it. In this benchmark I’ve used checked<\/code> explicitly, but the more common form is with the whole project compiled with <CheckForOverflowUnderflow>true<\/CheckForOverflowUnderflow><\/code> in the .csproj, such that this checked<\/code> becomes implicit. After the change, the range analysis sees that value<\/code> is in the range [0, 100]<\/code>, knows byte<\/code> fits values up to 255, and elides the check.<\/p>\n
    dotnet\/runtime#128620<\/a> further teaches range analysis the possible results of leading-zero count, trailing-zero count, and population count instructions. Those results are often used to index small lookup tables… knowing their bounds lets the JIT remove the bounds check.<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Numerics;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private static readonly int[] s_lookup =\r\n        Enumerable.Range(0, 33).Select(i => i * i).ToArray();\r\n    private uint[] _values;\r\n\r\n    [GlobalSetup]\r\n    public void Setup()\r\n    {\r\n        Random rng = new(42);\r\n        _values = Enumerable.Range(0, 1024).Select(i => (uint)rng.Next(1, int.MaxValue)).ToArray();\r\n    }\r\n\r\n    [Benchmark]\r\n    public int SumLookupByLeadingZeroCount()\r\n    {\r\n        int sum = 0;\r\n        foreach (var v in _values)\r\n            sum += s_lookup[BitOperations.LeadingZeroCount(v)];\r\n\r\n        return sum;\r\n    }\r\n}<\/code><\/pre>\n
    The lookup improves because the JIT now knows LeadingZeroCount(uint)<\/code> is between 0 and 32 and can remove the bounds check.<\/p>\n\n\n\n\n\n\n
    Method<\/th>\nRuntime<\/th>\nMean<\/th>\nRatio<\/th>\n<\/tr>\n<\/thead>\n
    SumLookupByLeadingZeroCount<\/td>\n.NET 10.0<\/td>\n516.1 ns<\/td>\n1.00<\/td>\n<\/tr>\n
    SumLookupByLeadingZeroCount<\/td>\n.NET 11.0<\/td>\n438.5 ns<\/td>\n0.85<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    The JIT is also able to conditionally apply range check-based elision via “cloning”. Cloning is a mechanism where the JIT takes one piece of code and duplicates it. One of the copies it leaves as it was originally, and the other copy it special cases. So, for example, if you had code like:<\/p>\n
    int value = array[i];<\/code><\/pre>\n
    the JIT could theoretically clone that in order to avoid the implicit bounds check, e.g.<\/p>\n
    int value;\r\nif ((uint)i < array.Length)\r\n{\r\n    \/\/ no bounds check emitted by JIT, e.g.\r\n    value = Unsafe.Add(ref MemoryMarshal.GetArrayDataReference(array), i);\r\n}\r\nelse\r\n{\r\n    \/\/ bounds check emitted\r\n    value = array[i];\r\n}<\/code><\/pre>\n
    That particular code looks silly, as we’re just trading an implicit bounds check for an explicit one. It becomes less silly when the JIT is able to elide multiple bounds checks with a single branch, e.g.<\/p>\n
    int sum;\r\nif (4 < array.Length)\r\n{\r\n    \/\/ zero bounds checks\r\n    ref int startRef = ref MemoryMarshal.GetArrayDataReference(array);\r\n    sum =\r\n        startRef +\r\n        Unsafe.Add(ref startRef, 1) +\r\n        Unsafe.Add(ref startRef, 2) +\r\n        Unsafe.Add(ref startRef, 3);\r\n}\r\nelse\r\n{\r\n    \/\/ potentially four bounds checks\r\n    sum =\r\n        array[0] +\r\n        array[1] +\r\n        array[2] +\r\n        array[3];\r\n}<\/code><\/pre>\n
    Such optimizations are already handled in the JIT, via its optRangeCheckCloning<\/code> phase. It groups bounds checks from a basic block, emits one guard for the largest required range, and duplicates the affected code into a fast path where the individual checks can be removed and a fallback path where they remain. However, one long-standing limitation of range-check cloning is that it refused to process the last statement of any “terminator” block, a block that ends with a jump or return instruction. For a method like:<\/p>\n
    static int ArrayAccess(int[] abcd) => abcd[0] + abcd[1] + abcd[2] + abcd[3];<\/code><\/pre>\n
    all four array accesses live in the return statement, the last statement of a return block, so nothing got cloned and the hot path retained four separate bounds checks. In .NET 11, dotnet\/runtime#124705<\/a> removes that restriction, making the return statement eligible for range-check cloning and allowing a single fast-path guard to cover all four accesses.<\/p>\n
    But even without range-check cloning, there’s really no reason such accesses should require four bounds checks: the JIT should be able to see that the array or span needs to have a length of at least 4 and guard all accesses by that single check. If there were intervening operations that had side effects, the JIT would need to maintain order of operations, at least enough to maintain the observable behavior of those effects, but that’s not the case here. With dotnet\/runtime#127439<\/a> in .NET 11, the JIT will now coalesce those checks within a basic block, strengthening the first check to the largest constant index and removing the rest.<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private readonly int[] _values = Enumerable.Range(0, 16).ToArray();\r\n\r\n    [Benchmark]\r\n    public int Sum16()\r\n    {\r\n        int[] values = _values;\r\n        return\r\n            values[0] + values[1] + values[2] + values[3] +\r\n            values[4] + values[5] + values[6] + values[7] +\r\n            values[8] + values[9] + values[10] + values[11] +\r\n            values[12] + values[13] + values[14] + values[15];\r\n    }\r\n}<\/code><\/pre>\n
    In previous releases, you’d sometimes see a proactive developer doing a similar optimization manually, e.g. reordering the accesses in an example like that to put the largest read first. That’s no longer necessary.<\/p>\n\n\n\n\n\n\n
    Method<\/th>\nRuntime<\/th>\nMean<\/th>\nRatio<\/th>\n<\/tr>\n<\/thead>\n
    Sum16<\/td>\n.NET 10.0<\/td>\n2.958 ns<\/td>\n1.00<\/td>\n<\/tr>\n
    Sum16<\/td>\n.NET 11.0<\/td>\n1.828 ns<\/td>\n0.62<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Another bounds checking improvement comes in dotnet\/runtime#127488<\/a>, which actually targets explicitly-implemented bounds checks (rather than the implicit ones we’ve been discussing) and targets code that reads a fixed-size value from the end of a span, such as BinaryPrimitives.ReadInt32BigEndian(span.Slice(span.Length - 4))<\/code> behind a span.Length >= 4<\/code> guard, e.g.<\/p>\n
    if (span.Length >= 4)\r\n{\r\n    \/\/ Parse an int from the end of the span\r\n    ... = ReadInt32BigEndian(span.Slice(span.Length - 4));\r\n    ...\r\n}<\/code><\/pre>\n
    There shouldn’t be any additional bounds checking required here. However, Span.Slice<\/code> begins with:<\/p>\n
    if ((uint)start > (uint)_length)\r\n    ThrowHelper.ThrowArgumentOutOfRangeException();<\/code><\/pre>\n
    and ReadInt32BigEndian<\/code> begins with:<\/p>\n
    if (sizeof(T) > source.Length)\r\n    ThrowHelper.ThrowArgumentOutOfRangeException();<\/code><\/pre>\n
    so even though our span.Length >= 4<\/code> check should have been sufficient, we’re still ending up with two additional checks. To address that, the JIT needed two things.<\/p>\n
    First, it needed to be able to identify that x - (x + a)<\/code> is the same as -a<\/code>. Without this identity, length - (length - 4)<\/code> is just an opaque subtraction of two expressions with no obvious constant result. With the identity, the JIT can recognize the inner expression (length - 4)<\/code> as length + (-4)<\/code>, apply x - (x + a) == -a<\/code> with x == length<\/code> and a == -4<\/code>, and end up with -(-4) == 4<\/code>. Now ReadInt32BigEndian<\/code>‘s check against 4 becomes 4 >= 4<\/code>, which the JIT can trivially see is true.<\/p>\n
    Second, Slice(start)<\/code> must establish that start<\/code> is between zero and the span’s length. When start<\/code> is length - 4<\/code>, the existing length >= 4<\/code> guard proves the result is non-negative, while subtracting a positive constant means the result can’t exceed length<\/code>. The improved range analysis connects that guard to the subtraction and removes Slice<\/code>‘s check.<\/p>\n
    Both fixes together mean the above example now elides both extra bounds\nchecks. That’s useful in particular for libraries like parsers, network\nprotocol implementations, and cryptographic code, all of which frequently on\nhot paths do things like “read the last N bytes of a buffer.”<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System.Buffers.Binary;\r\nusing System.Runtime.CompilerServices;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[DisassemblyDiagnoser]\r\n[HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private readonly byte[] _buffer = new byte[64];\r\n\r\n    [Benchmark]\r\n    public int ReadLastInt32() => ReadLastInt32(_buffer);\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static int ReadLastInt32(ReadOnlySpan<byte> span)\r\n    {\r\n        if (span.Length >= sizeof(int))\r\n        {\r\n            return BinaryPrimitives.ReadInt32BigEndian(span.Slice(span.Length - sizeof(int)));\r\n        }\r\n\r\n        return -1;\r\n    }\r\n}<\/code><\/pre>\n
    In .NET 10, the helper is 73 bytes and includes both additional checks and\ntheir throw paths:<\/p>\n
    ; x64\r\ncmp       ecx,4\r\njl        RETURN_MINUS_ONE\r\nlea       edx,[rcx-4]\r\ncmp       edx,ecx\r\nja        THROW_SLICE\r\nmov       r8d,edx\r\nadd       rax,r8\r\nsub       ecx,edx\r\ncmp       ecx,4\r\njl        THROW_READ\r\nmovbe     eax,[rax]<\/code><\/pre>\n
    In .NET 11, the helper is 28 bytes, and only the original length guard remains:<\/p>\n
    ; x64\r\ncmp       ecx,4\r\njl        RETURN_MINUS_ONE\r\nadd       ecx,-4\r\nadd       rax,rcx\r\nmovbe     eax,[rax]<\/code><\/pre>\n
    dotnet\/runtime#122040<\/a> and dotnet\/runtime#127117<\/a> similarly help to remove bounds checks involving span.Slice<\/code>. Vectorized loops often work through a span a chunk at a time, slicing off the elements they’ve already processed. The JIT hasn’t always been able to keep track of how those progressively smaller slices relate to the original span, so it could end up checking the same limits again on each iteration. These changes improve that tracking, enabling more of those repeated checks to be removed.<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing System.Runtime.CompilerServices;\r\nusing System.Runtime.Intrinsics;\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[DisassemblyDiagnoser, HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private readonly int[] _data = Enumerable.Repeat(1, 1_024).ToArray();\r\n\r\n    [Benchmark]\r\n    public Vector256<int> CreateFromSlice() => CreateFromSlice(_data);\r\n\r\n    [Benchmark]\r\n    public int SumSliced() => SumSliced(_data);\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static Vector256<int> CreateFromSlice(Span<int> values)\r\n    {\r\n        if (values.Length < 16)\r\n            return default;\r\n\r\n        return Vector256.Create(values.Slice(8));\r\n    }\r\n\r\n    [MethodImpl(MethodImplOptions.NoInlining)]\r\n    private static int SumSliced(ReadOnlySpan<int> data)\r\n    {\r\n        Vector128<int> sum = default;\r\n        while (data.Length >= Vector128<int>.Count)\r\n        {\r\n            sum += Vector128.Create(data);\r\n            data = data.Slice(Vector128<int>.Count);\r\n        }\r\n\r\n        int result = Vector128.Sum(sum);\r\n        foreach (int value in data)\r\n            result += value;\r\n\r\n        return result;\r\n    }\r\n}<\/code><\/pre>\n
    In .NET 10, the loop condition proves that at least one vector remains, but\nthe construction of the vector from the current span performs the same check\nagain. .NET 11 retains the length relationship, so\nthe loop body begins directly with the vector addition:<\/p>\n
    ; x64, vector loop\r\n-cmp       esi, 4\r\n-jl        THROW_ARGUMENT_OUT_OF_RANGE\r\n-vpaddd    xmm6, xmm6, [rbx]\r\n-add       rbx, 10\r\n-add       esi, 0FFFFFFFC\r\n-cmp       esi, 4\r\n+vpaddd    xmm0, xmm0, [rax]\r\n+add       rax, 10\r\n+add       ecx, 0FFFFFFFC\r\n+cmp       ecx, 4\r\n jge       LOOP<\/code><\/pre>\n
    We saw earlier how range-check cloning enables duplicating a sequence of instructions in order to eliminate bounds checks. “Loop cloning” extends that to a whole loop. Consider a loop that processes the first count<\/code> elements of an array:<\/p>\n
    for (int i = 0; i < count; i++)\r\n    sum += values[i];<\/code><\/pre>\n
    The test i < count<\/code> doesn’t by itself prove that i < values.Length<\/code>, so by default the compilation would need a bounds check in the body, which would mean a bounds check for every values[i]<\/code> access. Loop cloning gives the JIT another option. Instead of generating the equivalent of:<\/p>\n
    for (int i = 0; i < count; i++)\r\n    sum += values[i]; \/\/ bounds check!<\/code><\/pre>\n
    it can generate the equivalent of:<\/p>\n
    if ((uint)count <= (uint)values.Length)\r\n{\r\n    \/\/ no bounds checks\r\n    ref int startRef = ref MemoryMarshal.GetArrayDataReference(values);\r\n    for (int i = 0; i < count; i++)\r\n    {\r\n        sum += Unsafe.Add(ref startRef, i);\r\n    }\r\n}\r\nelse\r\n{\r\n    \/\/ bounds check per iteration\r\n    for (int i = 0; i < count; i++)\r\n    {\r\n        sum += values[i];\r\n    }\r\n}<\/code><\/pre>\n
    For the common case where the iteration is in bounds, execution proceeds through a cloned loop with no per-iteration bounds checks, whereas the original checked loop remains as the fallback that preserves exceptional behavior for invalid inputs. The normal path pays for one guard and avoids a check on every iteration, but that comes at the expense of duplicating code. The JIT therefore needs to apply the optimization selectively.<\/p>\n
    The JIT has long employed loop cloning, but it didn’t always kick in even in cases it seemed applicable. The previous example showed loop cloning with <<\/code> in the iteration condition. For whatever reason, however, some developers used !=<\/code>, and loop cloning didn’t apply (I’m guessing they used !=<\/code> because they thought it was more efficient, and they actually end up deoptimizing). Thanks to dotnet\/runtime#129268<\/a>, in .NET 11 !=<\/code> is now also handled, as long as specific conditions are met, such as the stride being exactly 1 or -1, e.g. i++<\/code> qualifies, while i += 2<\/code> doesn’t. dotnet\/runtime#129303<\/a> also improves loops that terminate with i != bound<\/code>, giving the JIT a tighter understanding of the values i<\/code> can take and allowing it to remove some bounds checks even when it can’t clone the whole loop.<\/p>\n
    Lookahead in arrays and spans is another recurring pattern, especially in parsers. dotnet\/runtime#124242<\/a> and dotnet\/runtime#125235<\/a> recognize conditions such as (uint)(i + 2) < (uint)span.Length<\/code> and use that relation to remove the follow-on checks for span[i + 1]<\/code> and span[i + 2]<\/code>. Consider this benchmark:<\/p>\n
    \/\/ dotnet run -c Release -f net10.0 --filter \"*\" --runtimes net10.0 net11.0\r\n\r\nusing BenchmarkDotNet.Attributes;\r\nusing BenchmarkDotNet.Running;\r\nusing System;\r\nusing System.Linq;\r\n\r\nBenchmarkSwitcher.FromAssembly(typeof(Benchmarks).Assembly).Run(args);\r\n\r\n[HideColumns(\"Job\", \"Error\", \"StdDev\", \"Median\", \"RatioSD\")]\r\npublic class Benchmarks\r\n{\r\n    private readonly string _text = string.Concat(Enumerable.Repeat(\"%FE\", 128));\r\n\r\n    [Benchmark]\r\n    public bool ContainsPercentFF()\r\n    {\r\n        ReadOnlySpan<char> span = _text;\r\n        for (int i = 0; i < span.Length; i++)\r\n        {\r\n            if (span[i] == '%' &&\r\n                (uint)(i + 2) < (uint)span.Length &&\r\n                span[i + 1] == 'F' &&\r\n                span[i + 2] == 'F')\r\n            {\r\n                return true;\r\n            }\r\n        }\r\n\r\n        return false;\r\n    }\r\n}<\/code><\/pre>\n\n\n\n\n\n\n
    Method<\/th>\nRuntime<\/th>\nMean<\/th>\nRatio<\/th>\n<\/tr>\n<\/thead>\n
    ContainsPercentFF<\/td>\n.NET 10.0<\/td>\n232.1 ns<\/td>\n1.00<\/td>\n<\/tr>\n
    ContainsPercentFF<\/td>\n.NET 11.0<\/td>\n194.9 ns<\/td>\n0.84<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Several smaller changes broaden the range of code from which the JIT can remove bounds checks:<\/p>\n