eliding

[SimonCropp]

thoughts on eliding some of those asyncs?

[chrissainty]

I had to google that one, I'll add it to my word of the day list!

What is the benefit here? It seems to go against the async guidance from David Fowler (reference: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md#prefer-asyncawait-over-directly-returning-task)

[SimonCropp]

i find it interesting the way async is treated. Much of the advice seems to be based on "people are not capable of understanding it, so dont tech the advances scenarios, just tell people to avoid them". so lets take async out of the picture, and instead use the

Lets say you are doing a helper method that returns all temp files:

Would you do this:

IEnumerable<string> GetTempFiles()
{
    return Directory.EnumerateFiles(Path.GetTempPath());
}

or this:

IEnumerable<string> GetTempFiles()
{
    foreach (var file in Directory.EnumerateFiles(Path.GetTempPath()))
    {
        yield return file;
    }
}

the first has similar behaviors and caveats to a direct Task return. the second has similar behaviors and caveats to await.

For me, with both async and yield state machines, i prefer direct return due to the less code. The effects on perf, memory and assembly size are a positive side effect. The impacts on stack traces and exceptions handling i have not found to be a problem.

But obviously this is just my preference :)

[SimonCropp]

also that advice is "AspNetCoreDiagnosticScenarios" and in the aspnet core repo there are 1801 instance of non awaited Task returns. admittedly some of those would be interfaces method definitions and some are returning Task.CompletedTask, but the majority are eliding

[SimonCropp]

to specifically answer "What is the benefit here"

• less IL = smaller assembly + faster JIT + smaller mem footprint when assembly is loaded
• no state machine = less mem uses + less GC pressure + faster due to no instantiation and execution of state machine

But as i said for me, is i primarily about less code

[chrissainty]

Thanks for taking the time to give such a detailed response @SimonCropp, it's much appreciated.

To give you some reference around my question, I've never had to write any performance sensitive code so I've just followed the guidance of awaiting rather than returning. The type of performance/memory benefits are just unknown to me. So I really appreciate the content of your response.

Based on what you've said it seems like a good change to make. I'll look at merging this over the weekend