Subject: Re: [boost] [Countertree + Suballocator] New Version
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-04-15 08:23:50
On 14/04/12 19:43, Francisco José Tapia wrote:
> I am not theoretical. To write code is my hobby , not my work. And after my
> work and my family, in my free time , I like to think about algorithms and
> to write them.
> I would know all the details about the GCC std::allocator ( named
> new_allocator) examining the code, but I have not time.I don't know what
> must do a pool allocator and how manage the memory.
> I like the simple and economical things, and the suballocator is designed
> according this.
So you're clearly saying you have little time to commit to this, and do
not have the desire to clarify things and employ rigor in your developments.
Therefore I do not think your libraries would ever be suitable for
inclusion in Boost.
> According my information ( perhaps I am wrong). In the boost library you
> have two allocators : boost::pool_allocator and boost::fast_pool_allocator.
> The first fail when must allocate 50.000.000 elements because the time was
> excessive. The second is fast, an excelent allocator, but have problems
> with the memory. If you allocate many elements and check the memory used,
> deallocate all the elements and check the memory again, you can see it is
> using the same amount of memory
As the documentation states, pool_allocator is for vector-like
allocation, while fast_pool_allocator is for node-like allocation.
The fact the memory is not being freed is by design, this is what a pool
I would guess that to get what you want, you should use an instance of a
pool by container, not the singleton global pool.
> The suballocator have several advantages compared with the
> boost::fast_pool_allocator :
> a) It is a byte faster. (This is the less important question)
Being a bit faster is a poor argument. It really depends on the cases,
and you can make benchmarks mean whatever you want them to by picking
the cases where your approach is the most useful.
> b) The allocator can be used with any allocator. If you have an allocator
> for share memory , you can't use the fast_pool_allocator
Working as an allocator adaptor is indeed a good thing.
> c) If in your program you are using a fast_pool_allocator,and in a moment
> have a peak of work, the memory used by the program grows. But when the
> work return to low level, the program continues using the same amount of
> memory. If you use a suballocator, probably the memory used by the program
Doing this is the conservative choice taken by most malloc/free
implementations. It however comes at a great cost in performance,
especially when node-like containers are concerned.
The solution to this problem is to have several instances of pool
allocators working independently, with the ability to free a whole pool
and everything inside it at any time.
This is region-based memory management.