ソケット上で動作することを目的としたメッセージキューを作成しています。さまざまな理由から、キューメモリをユーザースペースに配置し、キューをそれぞれのソケットに排出するスレッドを作成したいと考えています。
メッセージはメモリの小さな塊（おそらく4〜4Kバイト）になるため、断片化を回避するには、malloc（）メモリを常に回避する必要があると思います。
動作モードは、ユーザーがsend（msg）のようなものを呼び出し、メッセージがキューメモリにコピーされ、都合の良いときにソケットを介して送信されるというものです。
私の質問は、可変サイズのデータのチャンクをstd::queueやstd::vectorのようなものに保存する「良い」方法があるのか、それともメモリプールをまとめて処理するルートをたどる必要があるのかということです。その中から自分の割り当て？
大きな循環バッファーを作成し、チャンクからそのバッファーにデータをコピーして、ペアを{start pointer, length}キューに格納できます。チャンクは消費されるのと同じ順序で割り当てられるため、オーバーラップをチェックする計算は比較的簡単です。
最近のメモリ アロケータは非常に優れているため、「プレーンな」アロケータに基づくソリューションが同等のパフォーマンスを示しても驚かないでしょう。
メモリプールの負荷をBoost.Poolに委任できます。
4K 未満の場合、断片化がまったくない可能性があります。アプリケーションを実行するOSについては言及していませんが、LinuxまたはWindowsの場合、このサイズのブロックを処理できます. 少なくとも、独自のプールを作成する前にこれを確認してください。たとえば、この質問を参照してください:スモール ブロック アロケータに関する質問
大量のデータ パケットがキューに入れられることが予想されない限り、私はおそらく のプールを作成しvector<char>、それぞれに (たとえば) 8K を予約します。パケットの処理が終わったら、ベクターを捨てるのではなく、リサイクルします (つまり、プールに戻して、再び使用できるようにします)。
パケットが 4K を超えないことが本当に確実な場合は、明らかに 8K ではなく 4K に減らすことができますが、これが長時間実行されるプログラムであると仮定すると、サイズを最小化するよりも、再割り当てを最小化する方がおそらく多くのメリットがあります。個々のベクトルの。
明らかな代替手段は、アロケーターのレベルでこれを処理することです。そのため、ベクトルを再利用する代わりにメモリ ブロックを再利用するだけです。これにより、メモリ使用量を少し調整するのが少し簡単になります。私はまだブロックを事前に割り当てますが、64 バイト、256 バイト、1K、2K、4K (場合によっては 8K) など、いくつかのサイズしかありません。