[runtime-async] Optimize synchronous Task-returning wrappers used in async context

[jakobbotsch]

Developers frequently create synchronous Task-returning methods wrapping an async one to avoid additional state machines. For example, it is being done right now in #115688.

With runtime async this is a significant deoptimization. We should figure out how to optimize this pattern. One possible way would be to boost inlining for synchronous Task-returning methods calls by runtime async methods, and then adding an additional IR-based optimization of AsyncHelpers.Await(M()) later in the JIT (the current optimization is based on IL pattern recognition that will not kick in after inlining).

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[jakobbotsch]

Of course there is also a semantic difference in behavior between the two that we need to be careful to preserve.

[EgorBo]

What about this case:

async Task<int> Boo1()
{
    return 1;
}

Task<int> Boo2()
{
    return Task.FromResult(1);
}

? I know some analyzers (R#?) suggest to convert the former into the latter (the latter doesn't allocate since the task is cached)

[jakobbotsch]

That one isn't problematic, it won't be deoptimized or anything like that. Boo2 will be slightly less efficient (requiring some loads from the Task object).

With that said it is still reasonable (and easy) to optimize AsyncHelpers.Await(Task.FromResult(x)) => x, so no reason not to also do that.

[neon-sunset]

What about methods that are unlikely to get inlined (save for very generous inlining budget + DPGO)?

For example:

using System.Text;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Http;

public class ExampleMiddleware(RequestDelegate next)
{
    public Task Invoke(HttpContext context)
    {
        if (context.Request.Path != "some/path")
            return next(context);

        // More logic goes here
            
        return RespondSpecial(context);
    }

    static async Task RespondSpecial(HttpContext context)
    {
        context.Response.StatusCode = StatusCodes.Status200OK;
        context.Response.ContentType = "application/javascript";
        context.Response.Headers.CacheControl = "no-cache, no-store, must-revalidate";

        var somePayload = await Exampleservice.GetPayload(context);
        await context.Response.BodyWriter.WriteAsync(somePayload);
    }
}

[jakobbotsch]

What about methods that are unlikely to get inlined (save for very generous inlining budget + DPGO)?

For example:

using System.Text;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Http;

public class ExampleMiddleware(RequestDelegate next)
{
public Task Invoke(HttpContext context)
{
if (context.Request.Path != "some/path")
return next(context);

    // More logic goes here
        
    return RespondSpecial(context);
}

static async Task RespondSpecial(HttpContext context)
{
    context.Response.StatusCode = StatusCodes.Status200OK;
    context.Response.ContentType = "application/javascript";
    context.Response.Headers.CacheControl = "no-cache, no-store, must-revalidate";

    var somePayload = await Exampleservice.GetPayload(context);
    await context.Response.BodyWriter.WriteAsync(somePayload);
}

}

We can be very aggressive inlining Invoke into its async callable stub. This essentially ends up being a form of outlining as all async callers can share the async stub, so the duplicated code does not grow with number of callers in that case.