Recycle Freed Objects

Question

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

`

my another concern is suppose I need to manage recycled node using a queue or a list, then every time you call push(), you actually doing pop() on the pool and do push() to queue, it would be twice longer process, is it wise? — uray, Jun 01 '10 at 21:48

score 5 · Accepted Answer · edited May 23 '17 at 12:07

5

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

edited May 23 '17 at 12:07

Community

1
1

answered Jun 01 '10 at 21:42

Uri

88,451
51
221
321

score 1 · Answer 2 · edited May 23 '17 at 11:47

1

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.

edited May 23 '17 at 11:47

Community

1
1

answered Jun 01 '10 at 21:43

Bob Kaufman

12,864
16
78
107

score 1 · Answer 3 · answered Jun 01 '10 at 22:01

1

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

answered Jun 01 '10 at 22:01

Kornel Kisielewicz

55,802
15
111
149

score 0 · Answer 4 · answered Jun 01 '10 at 21:43

0

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.

answered Jun 01 '10 at 21:43

Amardeep AC9MF

18,464
5
40
50

score 0 · Answer 5 · answered Jun 01 '10 at 21:50

0

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.

answered Jun 01 '10 at 21:50

Don Wakefield

8,693
3
36
54

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 Jun 01 '10 at 22:12
@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 Jun 01 '10 at 22:15

Recycle Freed Objects

5 Answers5

Linked