Where to put await in an async method in this specific scenario

I was dicussing this with a colleague, and none of us were sure about it. Given these two methods using the asynchronous framework in C#, will there be a difference in performance between the two?

public async Task<ReadRespone> MethodA(ReadRequest request)
{
    var response = SynchronousReadThatTakesAWhileToExecute();
    return await Task.FromResult(new ReadResponse(response));
}

public async Task<ReadResponse> MethodB(ReadRequest request)
{
    var response = await Task.FromResult(SynchronousReadThatTakesAWhileToExecute());
    return new ReadResponse(response);
}

I was thinking that MethodA would perform the slow method syncronously, and then, since it only uses await for a trivial constructor, would in practice be a synchronous method, which would block execution for other threads. My colleague argued that both would be the same in practice, and that an async method should always return a task (but I'm thinking that await already "unboxes" the Task, and that an asynch method only needs to have an await Task somewhere in it to be correct).

Thanks

Your colleague is right. The MethodA and MethodB are practically equivalent. They are both asynchronous facades with synchronous implementations. Every time these methods are called, the calling thread does all the work, and then is handed back an already completed task (.IsCompleted == true). The task contains either the result or an exception. The async keyword only helps at simplifying the result/exception wrapping. You could implement exactly the same behavior without async, with a little more code:

public Task<ReadResponse> MethodC(ReadRequest request)
{
    try
    {
        var response = SynchronousReadThatTakesAWhileToExecute();
        return Task.FromResult(new ReadResponse(response));
    }
    catch (OperationCanceledException oce)
    {
        return Task.FromCanceled<ReadResponse>(oce.CancellationToken);
    }
    catch (Exception ex)
    {
        return Task.FromException<ReadResponse>(ex);
    }
}

The non-async method MethodC is intended for educational/demonstration purposes (it has a hidden bag). In practice using async for the wrapping is preferable.

As others have pointed out, there's practically no difference between those methods.

However, both methods are fully synchronous even though they have an asynchronous signature. I do not recommend this, since it will be confusing to anyone using this code.

If you can make it asynchronous, then do so:

public async Task<ReadRespone> MethodAsync(ReadRequest request)
{
  var response = await AsynchronousReadThatTakesAWhileToExecuteAsync();
  return new ReadResponse(response);
}

If the work is just synchronous (and you can't make it asynchronous), then make your method synchronous:

public ReadRespone Method(ReadRequest request)
{
  var response = SynchronousReadThatTakesAWhileToExecute();
  return new ReadResponse(response);
}

If you have synchronous work (and you can't make it asynchronous), and your method must be asynchronous (i.e., it's implementing an interface method), then you can make a synchronous implementation of an asynchronous interface. Note that this code runs synchronously, which is surprising to consumers, so I recommend documenting the possibly-synchronous nature in the interface docs itself.

#pragma warning disable 1998
public async Task<ReadRespone> MethodAsync(ReadRequest request)
#pragma warning restore 1998
{
  var response = SynchronousReadThatTakesAWhileToExecute();
  return new ReadResponse(response);
}

As others have pointed out, Task.FromResult() doesn't really work like that. It takes a value and returns a completed task, with the value. You want to use Task.Run or TaskFactory.StartNew.

public async Task<ReadResponse> Foo(ReadRequest request)
{
    var result = await Task.Run(SynchronousReadThatTakesAWhileToExecute);
    return new ReadResponse(result);
}

Notice the lack of brackes after SynchronousReadThatTakesAWhileToExecute. This is because I am not calling the function directly but passing it to Task.Run instead. This is functionally equivalent to passing () => SynchronousReadThatTakesAWhileToExecute() to Task.Run as an argument.

Editing my response so that it actually answers the question:
The provided two options are pretty much identical performance-wise.

They are basically the same. Both will perform blocking work without giving the control back to the calling method. Async state machine generated by compiler will "shortcut" if the task has already finished and actually will continue executing the current method. This can be demonstrated with the following code:

async Task FakeAsync()
{
    Console.WriteLine("Before IN FakeAsync");
    await Task.CompletedTask;
    Thread.Sleep(500); // "simulate" CPU-bound work
    Console.WriteLine("After IN FakeAsync");
}

async Task RealAsync()
{
    Console.WriteLine("Before IN RealAsync");
    await Task.Yield();
    Thread.Sleep(500); // "simulate" CPU-bound work
    Console.WriteLine("After IN RealAsync");
}

Console.WriteLine("Before FakeAsync");
var task =  FakeAsync();
Console.WriteLine("After FakeAsync");
await task;
Console.WriteLine("After await FakeAsync");
Console.WriteLine("---------");
Console.WriteLine("Before RealAsync");
var task1 = RealAsync();
Console.WriteLine("After RealAsync");
await task1;
Console.WriteLine("After await RealAsync");

Which will give the following output:

Before FakeAsync
Before IN FakeAsync
After IN FakeAsync
After FakeAsync
After await FakeAsync
---------
Before RealAsync
Before IN RealAsync
After RealAsync
After IN RealAsync
After await RealAsync

Note that for the FakeAsync both "IN" statements are executed before the rest of the calling method, while for the RealAsync the control is given back to the calling method (hence the "After RealAsync" between the "IN"s)

Aslo bear in mind that Task.Yield trick will work when no synchronization context is present so it can be used for some test scenarios, for "real life" the better approach is Task.Run:

async Task RealAsync()
{
    Console.WriteLine("Before IN RealAsync");
    await Task.Run(() => Thread.Sleep(500)); // "simulate" CPU-bound work)
    Console.WriteLine("After IN RealAsync");
}

Read more:

• Asynchronous programming with async and await documentation

• Asynchronous Programming in .NET - Introduction, Misconceptions, and Problems

• Threading in C# by Joseph Albahari (a bit dated but still amazing)