私の現在のプロジェクトのボトルネックはヒープの割り当てです...プロファイリングでは、1つの重要なスレッドがオペレーターと一緒に/オペレーター内で費やす時間の約50％を示していnewます。
アプリケーションはここでスタックメモリを使用できず、多くの1つの中央ジョブ構造を割り当てる必要があります。カスタムジョブ/バッファ実装：小さくて短命ですが、サイズは可変です。オブジェクト自体はヒープメモリstd::shared_ptr/std::weak_ptrオブジェクトであり、従来のC-Array（char*）ペイロードを伝送します。
さまざまな部分のランタイム構成とワークロードに応じて、300k〜500kのオブジェクトが作成され、同時に使用される場合があります（ただし、これは通常は発生しないはずです）。x64アプリケーションのメモリの断片化はそれほど大きな問題ではないため（ただし、x86を対象とした場合にも発生する可能性があります）。
速度とパケットスループットを向上させ、将来的にメモリの断片化を防ぐために、メモリ管理プールを使用することを考えていましたboost::pool。
ほとんどすべての例で固定サイズのオブジェクトを使用しています...しかし、可変長のペイロードを処理する方法がわかりませんか？このような単純化されたオブジェクトは、boost :: poolを使用して作成できますが、ペイロードをどう処理するかわかりませんか？で使え
boost:poolますか？class job { public: static std::shared_ptr<job> newObj(); private: delegate_t call; args_t * args; unsigned char * payload; size_t payload_size; }通常、shared_ptrへのすべての参照がスコープを使い果たすと、オブジェクトは破棄されます。shared-ptrをc-ptrに戻したくありません。オブジェクトの遅延破棄もパフォーマンスを向上させるために機能するはずであり、私が読んだものから、boost：poolを使用するとよりうまく機能するはずです。プールがsmart_ptrとの相互作用をサポートしているかどうかわかりませんか？別の、しかし風変わりな方法は、プールと一緒に作成時にshared_ptrへの参照を保存し、それらをブロックで解放することです。
誰かが2つの経験がありますか？boost：可変サイズのオブジェクトとスマートポインターの相互作用でのプールの使用？
ありがとうございました！