Комментарии 5
async/await, безусловно, имеет свою цену, но применяется он в 90% случаев для операций ввода-вывода (например, запрос к БД) длительность которых, как правило, на порядки превышает все возможные задержки вызванные созданием/удалением дополнительных объектов необходимых для async/await, но при этом выигрыш в производительности от того, что мы можем обойтись меньшим количеством потоков для обработки большого количества входящих запросов и легкость с которой можно этого достичь говорит, что: “всегда используйте async/await (для ввода/вывода), и не заморачивайтесь”. Если, таки, хочется “пооптимизировать” рассмотрите новый ValueTask (которого еще не было во времена написания оригинала этой статьи)
но применяется он в 90% случаев для операций ввода-вывода
Вот, мой любимый баг в .Net Core github.com/dotnet/corefx/issues/31557
ReadAsync из файла в 8 раз медленнее Read
Я думаю проблема тестируемого кода в том, что чтение производится очень маленькими фрагментами. Значительные задержки при операциях файлового ввода/вывода наблюдаются только в момент заполнения/сброса буфера, который очевидно имеет больший объем, чем массив используемый в операциях чтения из стрима. Получается, что подавляющее количество операций завершаются синхронно, поскольку происходит копирование из памяти в память, а не передача данных между памятью и устройством ввода вывода. Для этих синхронно выполненных операций мы и получаем основной оверхед из-за использования task'ов.
PS Собственно об этом же говорится в комментариях на SO, с чем автор вопроса в конце согласился
PS Собственно об этом же говорится в комментариях на SO, с чем автор вопроса в конце согласился
Спасибо за хороший комментарий — сделал новый перевод
Еще интересно, какова стоимость использования async/await на других платформах, и во что там генерируется подобный код.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Асинхронное программирование – производительность async: понять расходы на async и await