だから私はすでにtcp-serverSocketAsyncEventArgs
とsocket。***Asyncメソッドを書いた。しかし、私はandメソッドawait/async
を使用してコードを書く方法が大好きです。Stream.ReadAsync
Stream.WriteAsync
パフォーマンス/メモリに関して何か違いはありますか、それとも単に構文に違いをもたらしますか?
だから私はすでにtcp-serverSocketAsyncEventArgs
とsocket。***Asyncメソッドを書いた。しかし、私はandメソッドawait/async
を使用してコードを書く方法が大好きです。Stream.ReadAsync
Stream.WriteAsync
パフォーマンス/メモリに関して何か違いはありますか、それとも単に構文に違いをもたらしますか?
socketasynceventargs を使用する利点は、ガベージ コレクターの負担を軽減し、ソケットのバッファーをグループ化してメモリ不足の例外を防ぐことです。
SocketAsyncEventArgs のプールを使用すると、読み取りと書き込みの呼び出しごとに IAsyncResult を作成して収集する必要がなくなります。
次に、各 SocketAsyncEventArgs に大きな byte[] ブロックの一部を割り当てることができます。これにより、メモリの断片化が防止され、メモリ フットプリントの削減に役立ちます。これは技術的には Begin/End 呼び出しでも実行できますが、Begin/End メソッドで読み取りまたは書き込みが呼び出されるたびにブロックを割り当てるのではなく、各 SocketAsyncEventArgs に独自のバッファーを永続的に割り当てる方が簡単です。
重要な最後の違いは、MSDN ライブラリによると、ソケット バッファーがいっぱいになると、Begin/End Send メソッドがブロックされる可能性があることです。SocketAsyncEventArgs はブロックされません。代わりに、ソケット バッファー内のスペースの量に応じて一定量のバイトのみが書き込まれ、コールバックは書き込まれたバイト量を指定します。
エッジケースでない限り、利点は実際には目立ちません。指定された問題のいずれにも遭遇しない限り、最も快適で保守しやすいものを選択することをお勧めします。