BT

Async/Await- パフォーマンス上のオーバーヘッドと他の落とし穴

| 作者: Roopesh Shenoy フォローする 0 人のフォロワー , 翻訳者 編集部N フォローする 0 人のフォロワー 投稿日 2013年7月9日. 推定読書時間: 2 分 |

原文(投稿日:2013/07/04)へのリンク

Async/Awaitは、C# 5で導入された、間違いなく最も強力な言語フィーチャである。しかし、どのような落とし穴を避けなければならないのか?そして、これらのキーワードに関連したコストは、どうなのか?

MSDNの記事 “Best Practices in Asynchronous Programming” は、以下の点を強調している –

  • Event ハンドラーを除いて、非同期のvoidメソッドよりも非同期のTaskメソッドを使う。それらは異なるエラーハンドリングセマンティックを持つ。Marker MetroのKeith Patton氏もこれを詳細に説明している
  • ブロッキングとノンブロッキングのコードを混ぜるのを避ける – 混ぜるとデッドロック, もっと複雑なエラー処理、コンテキストスレッドの予期せねブロックの原因になり得る。
  • もし継続コードが元のコンテキストを必要としないなら、パフォーマンスを向上させるためにConfigureAwait(false)を使用する。– それは、スレッドプールのコンテキストで継続を実行する。これはまた、同期および非同期コードを混在させざるを得ない場合にデッドロックを回避するのに役立つ。サーバー側で使用した場合には、これには若干異なる配慮 があることに注意する。

RedGateのソフトウェアエンジニアであるChris Hurley氏は、async-awaitのCPU オーバーヘッドを説明し、サンプルコードをプロファイリングして同じ事を示している。–

  • “async”キーワードを伴うメソッドを呼び出すことは、ステートマシンを生成し、Taskを作り、その中で動き続ける作業を持ち、その実行コンテキストと同期コンテキストを取得する。
  • 示された例では、963のフレームワークメソッドが最初の呼び出しにおける比較的単純な非同期メソッドを初期化するために実行された。
  • コンテキストがキャッシュされているので、それ以降の呼び出しでは、オーバーヘッドがずっと小さい。
  • 非常に短い時間間隔(例えば1ms)で同期的に走るメソッドに対して、非同期オーバーヘッドは、呼び出し元のスレッドを実際にはもっと長くブロックする。例では、呼び出し元のスレッドがブロック解除されるまで45msもかかっていた。ループで実行する場合でも、後続の呼び出しのオーバーヘッドが小さくなったにもかかわらず、呼び出し元のスレッドはパフォーマンス上の利益を全く得ることができない。
  • 結論 – 非常に短いメソッドにasync/awaitを使うことを避ける、あるいはきついループ内でawaitステートメントを持つことをを避ける(代わりに非同期メソッドにループ全体を置く)

我々はこれらのキーワードを使う時の他の共通の落とし穴について既に扱った。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

特集コンテンツ一覧

.NETの派生を理解する

Wayne Citrin 2018年7月18日 午前3時44分

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT