Должны ли мы перейти на использование асинхронного ввода-вывода по умолчанию?
=============================================================================

С преимуществами асинхронного ввода-вывода и тем, что теперь довольно легко кодировать и составлять (используя Await и методы TAP), мне интересно, следует ли нам использовать асинхронность по умолчанию и настраивать производительность только с помощью синхронизации, когда это необходимо.

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

Для реализации адаптивных пользовательских интерфейсов разработчики WinRT сочли приемлемым предлагать асинхронные методы.

AFAIK Windows файловый ввод-вывод внутренне является асинхронным. Глядя на это наивно, мне не ясно, почему асинхронный ввод / вывод файла в .NET должен быть медленнее, чем синхронизация.

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

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

Если позже вы решите, что метод должен выполнить IO, вам придется изменить всю цепочку вызовов, чтобы переключиться на асинхронный. Это нелокальное изменение, распространяющееся на другие модули.

Вы можете'профиль t асинхронный IO. Инструменты профилирования ничего не подбирают. Если вы сделаете паузу в отладчике, то ни один из потоков не окажется в стеке. Кажется, никто ничего не делает. Тот's потому что асинхронный ввод-вывод не содержит потока. Это'Это просто структура данных (объект в ядре).

Решение также зависит от типа приложения. В приложении WinForms или WPF яЯ предпочитаю использовать async, потому что он так хорошо интегрируется в поток пользовательского интерфейса.

В настройках ASP.NET/WCF основным преимуществом является то, что вы нене исчерпывать пул потоков, пока вы вызываете долгосрочные бэкэнд-сервисы. Если вы неУ меня нет такой проблемы, и я думаю, что это довольно редко, вы получаете очень мало от асинхронного ввода-вывода. На самом деле вы теряете производительность по умолчанию.

В обстановке метро решение было принято за вас. Microsoft (законно) предпочла обменять продуктивность разработчиков на пользовательский опыт.

Так что это не четкое решение. Плюсы и минусы довольно слабы на данный момент. По этой причине я воздерживаюсь от однозначных рекомендаций. Это очень сильно зависит от конкретного случая.



`async` когда у вас есть естественно асинхронная операция и синхронный код в противном случае. Это'правда что`async` немного медленнее, но в большинстве случаев этокаквключаю радио в своем Хаммере " помедленнее.

В программах пользовательского интерфейса`async` увеличивает отзывчивость. В серверных приложениях`async` увеличивает масштабируемость.

AFAIK Windows файловый ввод-вывод внутренне является асинхронным. Глядя на это наивно, мне не ясно, почему асинхронный ввод / вывод файла в .NET должен быть медленнее, чем синхронизация.

Асинхронный код медленнее, потому что он должен распределять структуры для отслеживания асинхронной операции; синхронный код просто использует текущий поток (и его стек). Таким образом, сама операция не медленнее, но в целомНебольшое снижение скорости из-за большего давления на сборщик мусора.

Я вообще одобряю простоту и надежность и настраиваюсь только на производительность там, где это необходимо.

Согласен. Если у вас есть операция, которая естественно асинхронна (например, ввод / вывод), выставьте`async` API. И если у вас есть операция, которая является естественно синхронной, предоставьте синхронный API. У Стивена Туба есть пара отличных постов в блоге об этом ([Вот](https://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx) а также[Вот](https://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx)).