Recycle Freed Objects

问题:

suppose I need to allocate and delete object on heap frequently (of arbitrary size), is there any performance benefit if instead of deleting those objects, I will return it back to some "pool" to be reused later?

would it give benefit by reduce heap allocation/deallocation?, or it will be slower compared to memory allocator performance, since the "pool" need to manage a dynamic collection of pointers.

my use case: suppose I create a queue container based on linked list, and each node of that list are allocated on the heap, so every call to push() and pop() will allocate and deallocate that node:

`

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;
    }
}

`

回答1:

Pooling is a very common technique to avoid frequent allocations and deallocations. Some treat it as a design pattern. There are typically existing implementations, so there is no benefit to reinventing the wheel.

You may want to take a look at the question Object pool vs. dynamic allocation

回答2:

I had similar concerns when I asked this question. The answers may be insightful to you, especially those that address the concerns of memory fragmentation.

回答3:

You might take a look at Boost object pool -- for ideas, reference, or best for usage :>

回答4:

This is a particularly useful tool to make memory allocation more deterministic. It also reduces memory fragmentation if you preallocate the large blocks from which the pool is generated.

回答5:

Depending on your runtime library, you may have a 'good enough' allocator for many cases. That is, you should only build in a pool allocator for your application if you can demonstrate that you have a special use case, or a poor implementation of malloc in libc.

Since much of Doug Lea's work is present in the GNU lib, you might want to read about his experiences in A Memory Allocator.