非同期 I/O の利点と、(Await メソッドと TAP メソッドを使用して) コーディングと構成が非常に簡単になったため、デフォルトで非同期を使用し、必要なときにのみ同期を使用してパフォーマンスを調整する必要があるかどうか疑問に思っています。
非同期 I/O は、呼び出し元のスレッドを解放し、結果を待っている間に別のことを実行できるようにします。一方、非同期 I/O は同期よりも少し遅くなります。
レスポンシブ UI を強制するために、WinRT デザイナーは、非同期のみのメソッドを提供することが許容されることを発見しました。
AFAIK Windows ファイル I/O は内部的に非同期です。これを素朴に見ると、.NET の非同期ファイル i/O が同期よりも遅くなる理由がはっきりしません。
私は通常、シンプルさと堅牢性を好み、必要な場合にのみパフォーマンスを調整します。以前は、一部のサービスの呼び出しと、電話などのプラットフォームが非同期を強制する場合を除いて、デフォルトで同期を使用していました。非同期を使用して調整することはめったにありません。
C# 5 で async IO を使用するのは非常に簡単になりましたが、それに伴う生産性のコストは依然として存在します。たとえば、必要に応じて、以前はなかった新しいキーワードを振りかける必要があります。メソッドの戻り値の型を変更する必要があります。
後でメソッドが IO を実行する必要があると判断した場合は、コール チェーン全体を変更して非同期に切り替える必要があります。これは、他のモジュールに広がる非ローカルな変更です。
非同期 IO をプロファイリングすることはできません。プロファイリング ツールは何も検出しません。デバッガーを一時停止すると、どのスレッド スタックにも何もありません。誰も何もしていないようです。これは、非同期 IO がスレッドを保持しないためです。これは単なるデータ構造 (カーネル内のオブジェクト) です。
この決定は、アプリケーションの種類によっても異なります。WinForms または WPF アプリでは、UI スレッドにうまく統合されるため、async を使用したいと思います。
ASP.NET/WCF 設定の主な利点は、実行時間の長いバックエンド サービスを呼び出している間にスレッド プールを使い果たしないことです。そのような問題がなく、これはかなりまれだと思いますが、非同期 IO から得られるものはほとんどありません。実際、デフォルトではパフォーマンスが低下します。
メトロ設定では、決定はあなたのために行われました。Microsoft は (合法的に) 開発者の生産性とユーザー エクスペリエンスのトレードオフを選択しました。
したがって、明確な決定ではありません。現時点では、長所と短所はどちらも非常に弱いです。そのため、明確な推奨を差し控えさせていただきます。それは特定のケースに大きく依存します。
async自然に非同期操作がある場合は使用し、それ以外の場合は同期コードを使用することをお勧めします。少し遅いのは事実ですasyncが、ほとんどの場合、「ハマーのラジオの音量を上げる」のが遅くなるようなものです。
UI プログラムでは、async応答性が向上します。サーバー アプリでは、asyncスケーラビリティが向上します。
AFAIK Windows ファイル I/O は内部的に非同期です。これを素朴に見ると、.NET の非同期ファイル i/O が同期よりも遅くなる理由がはっきりしません。
非同期操作を追跡するために構造体を割り当てる必要があるため、非同期コードは遅くなります。同期コードは、現在のスレッド (およびそのスタック) を使用するだけです。そのため、動作自体は遅くはありませんが、ガベージ コレクターへの負担が増えるため、全体的にわずかに速度が低下します。
私は通常、シンプルさと堅牢性を好み、必要な場合にのみパフォーマンスを調整します。
同意します。本来非同期の操作 (I/O など) がある場合は、asyncAPI を公開します。また、本来同期的な操作がある場合は、同期 API を公開します。Stephen Toub は、これに関する素晴らしいブログ記事をいくつか持っています (こことここ)。