Использование асинхронного шаблона ожидания из статического метода, когда параллелизм не требуется

Question

Есть ли преимущество в использовании шаблона асинхронного ожидания / ожидания при синхронном запуске?

Например, в моем приложении у меня есть статические методы, которые вызываются cron (hangfire) для выполнения различных задач, связанных с вводом-выводом. Простой надуманный пример таков:

static void Run(string[] args)
{
    var data = Test(args);

    //..do stuff with returned data
}

public static List<string> Test(string[] args)
{
    return Db.Select(args);
}

Есть ли какое-либо преимущество в написании этого кода следующим образом:

static void Run(string[] args)
{

    var dataTask = await TestAsync(args);
    dataTask.Wait();

    //..do stuff with returned data
}

public static async Task<List<string>> TestAsync(string[] args)
{
    return await Db.SelectAsync(args);
}

Мой коллега говорит мне, что я должен всегда использовать этот шаблон и использовать асинхронные методы, если они доступны, как это добавляется в разделе оптимизации капота, но он не может объяснить, почему это так, и я не могу найти какое-либо четкое объяснение.

Если я напишу свой код с этим типом паттерна в моих статических методах, он будет выглядеть примерно так:

var data = someMethod();
data.Wait();
var data2 = someOtherMethod(data);
data2.Wait();

Я понимаю, что использование асинхронного шаблона ожидания при запуске большого количества одновременных задач, но когда код происходит из статического метода и должен запускаться в таком порядке, есть ли какая-то польза от этого? Каким образом я должен написать это?

Answer 1

как добавляет под оптимизацией капота, но он не может объяснить, почему это

Меня удивляет, как много людей считают, что асинхронность всегда лучший выбор, но они не могут сказать, почему. Это большое недоразумение в сообществе. К сожалению, Microsoft как бы подталкивает это понятие. Я полагаю, что они делают это, чтобы упростить руководство.

Async IO помогает в двух вещах: 1) сохранять потоки 2) упростить приложения с графическим интерфейсом, избавившись от управления потоками.

Большинство приложений полностью не зависит от количества запущенных потоков. Для этих приложений асинхронный ввод-вывод добавляет нулевую пропускную способность, требует дополнительных ресурсов процессора и усложняет код. Я знаю, потому что я измерил пропускную способность и масштабируемость. Я работал над многими приложениями.

В частности, сам IO не становится быстрее. Единственное, что меняется, - это способ инициирования и завершения вызова. Здесь вообще нет оптимизации ввода-вывода.

Используйте async, когда вам это удобно или у вас есть доказательства того, что количество запущенных потоков будет проблемой. Не используйте его по умолчанию, поскольку производительность будет ниже. Существуют дополнительные способы добавления ошибок. Инструменты хуже, код длиннее, отладка и профилирование труднее.

Конечно, нет ничего плохого в том, чтобы использовать его, если это правильный инструмент для работы.