3

I’ve worked on a baseline with code in this this form:

Var result = await Task.FromResult(_someObject.SomeNonAsyncMethod(someParameterObject));

From what I understand about Task.FromResult, this is simply packaging an object into a result form, not packaging a method into a task for asynchronous execution. Therefor the operations are adding extra overhead without any benefit.

Is this understanding correct?

Is this use of await doing anything useful in terms of performance?

Should await Task.FromResult ever be used in this way? (considering this line used alone - not implementing an interface or in a test, ect.)

Thanks in advance for any insight!

SW Dog
  • 158
  • 2
  • 16
  • see: https://stackoverflow.com/questions/19568280/what-is-the-use-for-task-fromresulttresult-in-c-sharp – Shaked Dahan Aug 10 '18 at 16:54
  • What happens when you're bound to an asynchronous framework, but you don't have any I/O to invoke? (e.g. an MVC delegating handler) – Kenneth K. Aug 10 '18 at 16:55
  • Possible duplicate of [What is the use for Task.FromResult in C#](https://stackoverflow.com/questions/19568280/what-is-the-use-for-task-fromresulttresult-in-c-sharp) – JSteward Aug 10 '18 at 17:38
  • @KennethK. You're saying that a conversion would be required to support some signatures, right? But that still wouldn't require this line, would it? – SW Dog Aug 10 '18 at 22:20

2 Answers2

5

There's no use for having both halves in the same line of code like that. However, it's useful for a function to package up its synchronous result in a Task in order to conform to an interface.

In some cases, a function may even have both synchronous and asynchronous execution. For example, there may be a synchronous lookup in a fast local cache, and on cache misses, a slow network operation. A function like this has to have a Task return type, which means the synchronous exits need to construct a Task from the already-known result.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
0

Sometimes you have to implement an interface, or override an abstract virtual function that is declared async, but there is no async function to call.

For instance, I have a method in an interface that fetches a person:

async Task<Person> FetchPersonAsync(int);

If you would want to fetch the person from some slow input, like from a database, or from the internet, or a file, then it would be meaningful to use the async function for this. However, if you have to read it from a local dictionary, for instance to mock in a unit test, then you don't have any async function to await for.

In cases there is no async function for you to await for, but you MUST implement the async function, use the FromResult:

async Task<Person> FetchPerson(int id)
{
    return await Task.FromResult<Person>(this.myPersonPictionary[id]);
}

For performance reasons, I would only do this if you really need too implement such a function, and you have nothing to await for.

Harald Coppoolse
  • 28,834
  • 7
  • 67
  • 116
  • 1
    `async` is not part of the method signature; it is merely an instruction to the compiler to introduce a state machine and allow usage of the `await` keyword. The reason any async method can be awaited is the fact that it returns a `Task`, not that it is marked with `async`. If you mark a method `async` in an interface, you get an error: The 'async' modifier can only be used in methods that have a body. – TheBuzzSaw Mar 04 '22 at 23:08
  • @TheBuzzSaw In that case, everything Harald said, except that the interface method returns something like Task instead of string, but your specific implementation of that interface method has no need to be async, in that case return Task.FromResult(... some string ...). – zumalifeguard Jul 25 '22 at 20:09