Re: [boost] [pool] Calling all library designers: The future of Boost.Pool???

Subject: Re: [boost] [pool] Calling all library designers: The future of Boost.Pool???
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-07-18 04:30:46

On Wed, Jul 18, 2012 at 7:29 AM, Joel Falcou <joel.falcou_at_[hidden]> wrote:

>
> As for Pooling, there is still some use cases on embedded systems where
> you are required to pool some Mb at the beginning of the applications then
> you want to go through normal allocator/container design to access it. Gb
> of RAM on COTS computer are not the only use case around ;)
>

Exactly. For example, for high performance video games on any console,
there is no way you will avoid to have to pool memory in a way or another.
It is possible to not do this, but in most actino game context it is not
acceptable to have slow down because of allocations (though there are
diverse ways to fix this, pooling memory is a general one).
Also, and it's very important: budgeting memory is a very important
practice in some very high performance games.

Andrey Semashev  said:

> There is also an option to repurpose the library. Pooling raw memory may
> not
> be that needed today but pooling constructed objects is another story. More
> than once I had cases when constructing an object, including collateral
> resource allocation and initialization, is a costly operation and it is
> only
> natural to arrange a pool of such objects. While in the pool, the objects
> are
> not destroyed but merely "cleaned". An object can be retrieved and
> returned to
> pool multiple times, which saves the costly initialization. I could use a
> framework for building such pools. I think this is the most productive way
> of
> development of the library.

I was thinking is that mostly the Object Pool of Boost Pool was basically
what you describe? At least on the purpose, maybe not very efficient in the
implementation.

Joel Lamotte