デフォルトで非同期I/Oを使用するように切り替える必要がありますか？

Question

非同期I/Oの利点は、（AwaitとTAPメソッドを使用して）コードや構成を行うのが非常に簡単で、デフォルトで非同期を使用し、必要なときに同期を使用してパフォーマンスを調整する必要がある場合です。

非同期入出力は呼び出しスレッドを解放し、結果を待っている間に何か他のことを行うことを許可します。一方、非同期I/Oは同期より少し遅いです。

WinRTのデザイナーは、レスポンシブUIを強化するために、非同期のみのメソッドを提供することを認めました。

AFAIK WindowsファイルI/Oは内部的に非同期です。これをnaiveに見ると、.NETの非同期ファイルI/Oが同期よりも遅くなるのはなぜか分かりません。

私は一般的にシンプルさと堅牢性を好み、必要に応じてパフォーマンスを調整します。過去にはいくつかのサービスを呼び出すことを除いてデフォルトで同期を使用していましたが、電話機のようなプラットフォームでは非同期を適用していました。非同期を使用することでめったに調整されません。

Answer 1

async IOの使用はC＃5では非常に簡単になっていますが、それに伴う生産性のコストはまだあります。たとえば、必要に応じてどこにも新しいキーワードを振りかざす必要があります。メソッドの戻り値の型を変更する必要があります。

メソッドでIOを行う必要がある場合は、非同期に切り替えるためにコールチェーン全体を変更する必要があります。これは、他のモジュールに広がっている非ローカルな変更です。

async IOをプロファイルすることはできません。プロファイリングツールは何も拾わない。デバッガを一時停止すると、スレッドスタック上に何もありません。誰も何もしていないようです。これは、非同期IOがスレッドを保持していないためです。これは単なるデータ構造体（カーネル内のオブジェクト）です。

決定はアプリケーションの種類によっても異なります。 WinFormsやWPFのアプリケーションでは、UIスレッドにきれいに統合されているので、私はむしろasyncを使うでしょう。

ASP.NET/WCF設定の主な利点は、長期実行バックエンドサービスを呼び出すときにスレッドプールを使い果たしないことです。あなたがこのような問題を抱えておらず、これがまれであると思うなら、あなたは非同期IOからほとんど利益を得ることができません。実際、デフォルトではパフォーマンスが低下しています。

メトロ設定では、決定が下されました。マイクロソフト（合法的に）は、ユーザーエクスペリエンスのために開発者の生産性を交換しました。

したがって、明確な決定ではありません。この時点で長所と短所はどちらもかなり弱いです。そのため私は明確な勧告をしてはいけません。それは特定の場合に非常に依存します。

Answer 2

自然に非同期の操作がある場合はasyncを使用し、そうでない場合は同期コードを使用することをお勧めします。 asyncがやや遅くなっているのは事実ですが、ほとんどの場合、「あなたのHummerでラジオを鳴らす」ようなものです。

UIプログラムでは、asyncが応答性を向上させます。サーバーアプリケーションでは、asyncはスケーラビリティを向上させます。

AFAIK WindowsファイルI/Oは内部的に非同期です。これをnaiveに見ると、.NETの非同期ファイルI/Oが同期よりも遅くなるのはなぜか分かりません。

非同期操作を追跡するために構造体を割り当てる必要があるため、非同期コードが遅くなります。同期コードは現在のスレッド（およびそのスタック）を使用します。したがって、操作自体は遅くはありませんが、全体的にガーベッジコレクターの負荷が増すため、速度が少し低下します。

私は一般的にシンプルさと堅牢性を好み、必要に応じてパフォーマンスを調整します。

私は同意します。自然に非同期の操作（I/Oなど）がある場合は、async APIを公開してください。また、自然に同期する操作がある場合は、同期APIを公開してください。 Stephen Toubにはこれに関する素晴らしいブログ記事がいくつかあります（hereとhere）。