4

ヒープ上のオブジェクトを頻繁に (任意のサイズで) 割り当てて削除する必要があるとします。これらのオブジェクトを削除する代わりに、後で再利用するために「プール」に戻した場合、パフォーマンス上の利点はありますか?

「プール」はポインタの動的コレクションを管理する必要があるため、ヒープの割り当て/割り当て解除を減らすことでメリットがありますか?または、メモリアロケータのパフォーマンスと比較して遅くなります。

私の使用例: リンクされたリストに基づいてキュー コンテナーを作成し、そのリストの各ノードがヒープに割り当てられているとします。そのため、push() と pop() を呼び出すたびに、そのノードが割り当てられ、割り当てが解除されます。

`

template <typename T> struct QueueNode {
    QueueNode<T>* next;
    T object;
}

template <typename T> class Queue {
    void push(T object) {
        QueueNode<T>* newNode = QueueNodePool<T>::get(); //get recycled node
        if(!newNode) {
            newNode = new QueueNode<T>(object);
        }
        // push newNode routine here..
    }
    T pop() {
        //pop routine here...
        QueueNodePool<T>::store(unusedNode); //recycle node
        return unusedNode->object;
    }
}

`

4

5 に答える 5

5

プーリングは、頻繁な割り当てと割り当て解除を回避するための非常に一般的な手法です。デザイン パターン として 扱う ものもあ る。通常、既存の実装が存在するため、一からやり直すメリットはありません。

オブジェクトプールと動的割り当ての質問をご覧になることをお勧めします。

于 2010-06-01T21:42:58.200 に答える
1

アイデア、参照、または使用に最適な場合は、Boostオブジェクトプールをご覧ください:>

于 2010-06-01T22:01:57.163 に答える
1

この質問をしたとき、私は同様の懸念を持っていました。特にメモリの断片化の問題に対処する答えは、あなたにとって洞察に満ちているかもしれません。

于 2010-06-01T21:43:17.550 に答える
0

これは、メモリ割り当てをより確定的にするための特に便利なツールです。また、プールの生成元となる大きなブロックを事前に割り当てると、メモリの断片化が減少します。

于 2010-06-01T21:43:31.107 に答える
0

ランタイム ライブラリによっては、多くの場合、「十分な」アロケーターを使用できます。つまり、特殊なユース ケースがあること、または libc での malloc の実装が不十分であることを示すことができる場合にのみ、アプリケーションのプール アロケータをビルドする必要があります。

Doug Lea の作業の多くは GNU lib に存在するため、 A Memory Allocatorで彼の経験について読みたいと思うかもしれません。

于 2010-06-01T21:50:56.480 に答える