8
私は答えたいバッファとメモリプールに関するいくつかの質問があります。メモリプールとバッファC++
私は〜50-100 + msg /秒を送受信しているサーバーがあります。すべてのメッセージはさまざまなサイズで表示されます。ここでメモリ管理の最善を尽くすにはどうしたらいいですか？私の当初の計画では、固定サイズのバッファ・ノードを使用していたし、それらをプールし、のようなもの：MSGが送信されたときに
struct buffer{
uint8_t data[512];
uint32_t end;
buffer* next;
}
buffer* b = pool_get_new_buffer();
だから、私はサイズに応じて1つまたは複数のバッファを作成し、それらを一緒にリンクします。この方法では、プール内の断片化を恐れることはありません。 （または私が思うもの）atleast。しかし、小さなmsgでは、そのスペースの無駄です。
しかし、インターネットでコードをチェックしていくうちに、誰もこのアプローチを使用していないようです。だから、より良いアプローチは何でしょうか？ msgサイズに応じてプールからメモリを割り当てますか？
編集： ここからは、異なるアプローチのより独立した比較があります。
私が推測している連鎖バッファーアプローチを使用すると、フラグメント化を最小限に抑えますが、一方で、チェーン内のすべてのバッファーに対してmemcpyを実行するとコストがかかります。しかし、大方の人がこのアプローチをとにかく選択しているにもかかわらず、十分な大きさのバッファを割り当てて、1つのmemcpyを実行することは、やはり欠点があります。
あなたの考えは良いです。あなたはただそれを拡張する必要があります（http://en.wikipedia.org/wiki/Buddy_memory_allocation）。要件は[一般的なアロケータ]（http://g.oswego.edu/dl/html/malloc.html）のように見えます。または、メモリを初期化する必要がある場合は、[SLAB]（http://en.wikipedia.org/wiki/Slab_allocation）アロケータを使用しますか？ –
LinuxとBSDは既にかなり良いアロケータを持っているのであまり普及していません。 Windowsのデフォルトアロケータはかなりひどいですが、MSVC2010以降、並行性CRTの一部としてかなり良いものを出荷しています。あなたが言及したスキームは、Linux/BSDがソケットのために内部的に使うものです。 –
しかしそれはなぜ普及していないのですか？その実装が難しいためですか？あなたがこのようにすることでそれほど多くを得ることができないからですか？なぜ、ある方法が他の方法よりも優先されているかをより具体的に知ることはいいでしょう。 – user2010820