Object pool vs. dynamic allocation

Question

When should one prefer object pool over dynamically allocated objects?

I need to create and destroy thousands of objects per second. Is it by itself enough to decide in favor of object pool?

Thanks.

Mchail

As usual - it depends. And if you can use an object pool, you obviously don't "need" to create and destroy things. So wee need more detail. – Originality

Answer 1

Yes, this is enough to decide in favor of object pool.

Quoting Boost documentation

When should I use Pool?

Pools are generally used when there is a lot of allocation and deallocation of small objects. Another common usage is the situation above, where many objects may be dropped out of memory.

See Boost Pool library

Conscript

Answer 2

Measure, measure, measure. Then you'll know, and you won't have to rely on speculation or guidelines.

Also, if Dirk Grunwald's CustomMalloc is still available, give it a try. It synthesizes an implementation of malloc that is tuned to the needs of a single application.

Pergola

Answer 3

The expected cost of destructing the object, deallocation, allocation and construction is higher than the cost of reinitializing for a new use.

Aftershock

I would say "may be low" - it's entirely possible (even likely) the initialisation is the expensive stage. – Originality

I reformulated my answer. Reading the other answers, it seems that I'm the only one making a difference between objects pool (where one keeps a list of constructed objects for use) and memory pool (which is a memory management technique where one delay the deallocation -- and sometimes the destruction, sometimes the destruction is purely not done -- so that it is made in one step). – Aftershock

I'm not sure I understand what you're saying here. I always thought that the benefit of an object pool was only memory reuse? All new objects needs to be constructed and all old objects destructed anyway - you cannot save on that time? – Allbee

That's the difference I tried to hint to. What you describe is what I've always seen called "memory pools" (well, I've also seen lot of variants for that) What I call "objects pool" is a pattern where you keep already constructed objects in the pool and use them and put them pack in the pool without destructing them when you don't need them any more. With memory pool, the emphasis is on reducing the allocation/deallocation time, with objects pool, it is the construction/destruction time. Obviously, this is less generally applicable. – Aftershock

Thanks - I see now, I was only considering the memory pool case. – Allbee

Answer 4

Generally if you're creating and destroying thousands of objects a second you should at least use an object pool.

You could use a custom allocator which purely allocates objects of a specific size. Override new and pre allocate a heap specifically for your objects. Using a bit field and an array its relatively simple.

Basically a custom heap is more memory efficient if the objects are small (the heap overhead is quite high relative to small objects size); Its faster; It prevents heap fragmentation; And its easier to debug.

Strappado