views:

85

answers:

5

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

`

+2  A: 

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 http://stackoverflow.com/questions/1250983/object-pool-vs-dynamic-allocation

Uri
+1  A: 

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.

Bob Kaufman
A: 

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.

Amardeep
A: 

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.

Don Wakefield
Last time I checked, the default allocator that comes with glibc already implements free lists (aka pools) for small objects (up to 16 bytes, if I remember correctly... or was it 64?).
Emile Cormier
@Emile, thanks for that extra bit of info. I guess the biggest argument for custom pools is *not* knowing what libc your target customer will be using.
Don Wakefield
+1  A: 

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

Kornel Kisielewicz