C/Python でソケットをいじっていますが、Python 辞書からクライアント ソケットにヘッダーを送信する最も効率的な方法は何だろうと考えています。
私のアイデア:
sendすべてのヘッダーに呼び出しを使用します。長所: メモリ割り当てが不要です。短所:send呼び出しが多い -- おそらくエラーが発生しやすい。エラー管理はかなり複雑にする必要がありますsend呼び出しで、エラー チェックがはるかに簡単になります。短所: バッファが必要です :-) malloc/reallocかなり遅くなるはずreallocです。呼び出しを避けるために (大きすぎる) バッファを使用すると、メモリが浪費されます。ヒントはありますか？ありがとう ：-）
TCP 輻輳制御の仕組みにより、一度にすべてのデータを送信する方が効率的です。TCP は、「空中」 (送信されたがまだ確認応答されていない) を許可するデータの量のウィンドウを維持します。TCP は、戻ってくる確認応答を測定して、輻輳 (つまり、パケット損失) を引き起こさずに「空中」に保持できるデータ量を把握します。ウィンドウを埋めるのに十分なデータがアプリケーションから送信されない場合、TCP は正確な測定を行うことができないため、控えめにウィンドウを縮小します。
少数の小さなヘッダーしかなく、への呼び出しがsend立て続けに行われる場合、オペレーティング システムは通常、データをバッファリングし、すべてを 1 つのパケットで送信します。その場合、TCP 輻輳制御は実際には問題になりません。ただし、 への各呼び出しにsendは、ユーザー モードからカーネル モードへのコンテキスト スイッチが含まれるため、CPU オーバーヘッドが発生します。言い換えれば、アプリケーションでバッファリングする方が良いということです。
バッファリングを使用しない方がよい場合が (少なくとも) 1 つあります。それは、バッファがコンテキスト切り替えのオーバーヘッドよりも遅い場合です。Python で複雑なバッファーを作成する場合は、その可能性が非常に高くなります。CPython で書かれたバッファは、カーネルで細かく最適化されたバッファよりもかなり遅くなります。バッファリングは、購入するよりも多くの費用がかかる可能性があります。
迷ったら測る。
時期尚早の最適化は諸悪の根源です。ここでの効率の違いはかなり小さいです。これがアプリケーションのボトルネックであることをまだ確認していない場合は、作業を楽にする方法を選択してください。後でいつでも変更できます。
本当に大量のデータを送信する場合を除いて、おそらく1つのバッファーを使用する方がよいでしょう。バッファサイズを大きくするために等比数列を使用する場合、割り当ての数は償却定数になり、通常、バッファを割り当てる時間はそれに続きます。
send()呼び出しは、カーネル（ハードウェアを直接処理するOSの部分）へのラウンドトリップを意味します。単価は約数百クロックサイクルです。send()何百万回も電話をかけようとしない限り、これは無害です。
通常、バッファリングとはsend()、「十分なデータ」が収集されたときに、たまにのみ呼び出すことです。「十分」とは「メッセージ全体」を意味するのではなく、「カーネルラウンドトリップの単価を小さくするのに十分なバイト数」のようなものです。経験則として、8 kBのバッファー（8192バイト）は従来、適切であると見なされていました。
とにかく、すべてのパフォーマンス関連の質問については、実際の測定値に勝るものはありません。それを試してみてください。ほとんどの場合、心配する価値のある実際のパフォーマンスの問題はありません。