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 allocator is. 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 decrease.
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.