Optimize an async method that ends "return await e" to be non-async "return e"

[gafter]

this optimization would improve the performance of an async method whose only await appears at the end. Not when producing debug code and not when nested in a try block.

@jaredpar @VSadov

[VSadov]

This is basically the tail-call optimization for async methods.

@pharring

[svick]

Won't this change the semantics when e itself throws an exception (instead of returning a faulted Task)? Specifically, return e bubbles the exception up the call stack, while return await e puts it into the returned Task.

Though I guess something like this would work:

try
{
    return e;
}
catch (Exception ex)
{
    return Task.FromException(ex);
}

[jaredpar]

@svick yes it would change the call stack for exceptions of this nature.

[gafter]

@svick Given the proposed constraints, the callers will just bubble the exception up, so the end result is the same other than the fact that the call stack is different.

[svick]

@gafter I don't understand. Consider the following code:

Task<int> E()
{
    throw new Exception();
}

async Task<int> ReturnAwaitE()
{
    return await E();
}

Task<int> ReturnE()
{
    return E();
}

…

var t = ReturnAwaitE();
await t.ContinueWith(_ => {}); // await t, but don't throw if it's faulted
Console.WriteLine(t.Exception);

This code writes out the exception, but if I replace ReturnAwaitE(), with ReturnE(), it throws instead; so the end result is very different here.

Doesn't ReturnAwaitE fulfill your constraints (the method ends with return await, there is no other await, there is no try)? And isn't ReturnE how the optimized version would look like?

[jaredpar]

@svick this feature would not change exception semantics in that way. To do so would turn an optimization into a breaking change. The implementation of this would have to take exceptions into account when generating the code.

Even in this case though the compiler can generate much more efficient code than the state machine that is generated today:

Task<int> ReturnE()
{
  try {
    return E();
  } catch  (Exception e) {
    return Task<int>.FromException(e);
  }
}

[pharring]

👍 on the idea.
Note that the transform is valid even in the presence of .ConfigureAwait(false)
I had thought of doing this via an analyzer.
I think, in many cases, the extra try/catch is unnecessary. If an exception is thrown from an "await"-able method (instead of returning a faulted Task), then doesn't this indicate an exception in the task handling machinery? That's the sort of exception I'd be happy to let go up to the caller.

[svick]

@jaredpar Yeah, that breaking change was what I was afraid of. It wasn't clear to me from the initial description that this was what the optimization would do.

[jaredpar]

@pharring if there is another await in the function then the existing state machine code will handle it. If the return await call though is the only await then the compiler needs to generate the extra try / catch in many cases. Otherwise it changes the observable behavior of the method.

[pharring]

BTW, Task.FromException is an internal method.

[stephentoub]

@pharring, it was in 4.5, it isn't anymore.

[stephentoub]

ps Note, though, that the try/catch will also need to specialize catching an OperationCanceledException and returning a canceled task for that case, as that's what the async machinery does today.

[stephentoub]

pps And for it to actually remain semantically equivalent, it'd have to appropriately handle ExecutionContext. In particular, inside of an async method, changes made to ExecutionContext (e.g. putting something into the logical call context) will not be visible to the caller of the async method upon the return of the synchronous invocation.

[pharring]

This was proposed a couple of times already

[khellang]

👍 on this optimization!

[GSPP]

Is the C# team willing to take a dependency on the internals of TaskAwaiter here? Previously, that class was opaque and there wasn't any compiler knowledge about it built-in. From the languages point of view that class could do anything at all when awaited.

[yaakov-h]

Won't this remove the method in question from an exception stack trace?

Is there a way that this optimisation could be achieved whilst still preserving the stack trace?