Делать ли каскад методов асинхронными, если они могут возвращать просто Task<T>

#c_sharp #net #async_await #async #clr

Терзает вопрос, найти внятный ответ не могу. Гуглится не то.

Вот у меня есть действительно асинхронный метод, в котором несколько await'ов. Этот
метод вызывается на более верхнем уровне:

public async Task UpperLevelMethod()
{
    return await _component.RealyAsyncMethod();
}


Ну и так далее, по всем слоям приложения. 

Но ведь по идее, можно написать так:

public Task UpperLevelMethod()
{
    return _component.RealyAsyncMethod();
}


И вызов await UpperLevelMethod() будет корректно отрабатывать. И, на сколько я понимаю,
этот метод даже лучше, т.к. не будет создаваться дополнительные экземпляры IAsyncStateMachine,
поправьте, если я не прав.

Интересно, что авторы статей и книг в красках описывают последствия упаковки/распаковки,
но этот момент как-то упускается в разделе про асинхронность.

Есть ли какие-то подводные камни, у такого вызова? Либо, в случаях, когда не нужно
делать асинхронное продолжение, можно (а возможно даже лучше) делать метод не асинхронным?

P.S. Тот же Скит описывает, что для проверки аргументов лучше делать так:

public Task UpperLevelMethod(string arg)
{
    /*
    Проверка аргумента и выброс исключения в случае ошибки
    */
    return _component.RealyAsyncMethod();
}


Но он говорит именно про проверку аргументов, чтобы она проходила в синхронном режиме.
Об оптимизации - ничего.

Update: 
Консольное приложение, собраное в релизе, с таким кодом:

static void Main(string[] args)
{
    Task.Run(Foo5);
}

static async Task Foo1() => await Task.FromResult(5);

static Task Foo2() => Foo1();

static Task Foo3() => Foo2();

static Task Foo4() => Foo3();

static Task Foo5() => Foo4();


весит 8 192 байт, при добавлении await'ов - 10 240 байт.
    

Ответы

Ответ 1

Совершенно верно, лучше не писать лишний раз async если код работает и без него.
Нет никаких причин писать лишние слова async и await.