Runtime Async in.NET 11: The Real Changes

async and await have looked the same since C# 5.

This concerns what happens in he background, you write a method, mark it async, call with await, and the compiler turns it into an action that can pause and resume.

That translation has always been the compiler's.

In .NET 11, the runtime takes it back.

 

Throw this article i will explain what the compiler does today, why it costs what it costs, and what runtime async replaces it with.

First, what await actually has to solve

Take a simple method:

public async Task<string> FetchAsync(string url)
{
    return await service.GetAsync(url);
}

When we reach the await, the network call might take 200 milliseconds.

During those 200 milliseconds, there is no work to do. Blocking a thread to sit and wait would be wasteful.

So the method pauses, gives the thread back, and resumes later when the response arrives.

That raises a problem. A normal method lives on the stack. It runs top to bottom.

If you pause in the middle and come back later, possibly on a completely different thread, where did all our variables go?

Something has to remember.

How it has worked since 2012

Since C# 5, the compiler solves this by rewriting your method.

It takes your method and turns it into a small object, a state machine. That hold the following information:

• A position marker. Which await did we stop at?

• Your variables.

• A resume method. Your original method body, rewritten so it can be re-entered and jump back to where it stopped.

It works. It has worked well for thirteen years. But it comes costs.

What that design costs you

It allocates. When an await genuinely has to wait, that bookmark object moves to the heap. One allocation, every call.

It saves more than it needs to. The compiler has no way of knowing which variables will actually matter when execution resumes, so it keeps everything that might be needed.

What .NET 11 does differently

Runtime async moves the job from the compiler to the runtime.

The compiler stops generating the state machine object entirely. Instead, it leaves your method looking like you wrote it, with a marker that says "this method can pause here".

The runtime handle the pausing and resuming themselves.

This change a lot, because the runtime knows things the compiler never could:

• It saves only what is genuinely needed.

• It reuses objects instead of allocating fresh ones at every pause point.

What you actually notice

Cleaner stack traces

• Live stack traces show your real call chain.

• Debugging improves with it.

Less memory, a bit more speed

A community benchmark of a loop with ten awaits measured:

	Time	Memory allocated
Old approach	192.4 ns	1.61 KB
Runtime async	128.0 ns	928 B

About a third faster.

But if your await is a database query that takes 30 milliseconds, the query dominates and you will not notice 60 nanoseconds.

Trying it out

One property in your project file:

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <Features>runtime-async=on</Features>
</PropertyGroup>

Best ASP.NET Core 11.0 Hosting Recommendation

One of the most important things when choosing a good ASP.NET Core 11.0 hosting is the feature and reliability. HostForLIFE is the leading provider of Windows hosting and affordable ASP.NET Core, their servers are optimized for PHP web applications. The performance and the uptime of the hosting service are excellent and the features of the web hosting plan are even greater than what many hosting providers ask you to pay for. 

At HostForLIFE, customers can also experience fast ASP.NET Core 11 hosting. The company invested a lot of money to ensure the best and fastest performance of the datacenters, servers, network and other facilities. Its datacenters are equipped with the top equipments like cooling system, fire detection, high speed Internet connection, and so on. That is why HostForLIFE guarantees 99.9% uptime for ASP.NET Core. And the engineers do regular maintenance and monitoring works to assure its Orchard hosting are security and always up.