perfomance: memory cleanup for pool takes too long

[nobody]

hi,

In my project I use boost::pool because I have to 
instantiate millions of object at the beginning of the 
application, and only get rid of the at termination time.

I noticed that when processing large data
(which may require 1Gb memory for the application while 
it is running)
the application may finish its processing approx after 10 
seconds.
the cleanup part (which consists only of calling the pool 
release methods on allocated objects)
on the other hand, takes many minutes
(I usually give up after 5 minutes)

debugging the code i noticed that the while loop in
the nextof function 
(of SIMPLE SEGREGATED STORAGE.HPP)

takes many iterations.
this leads me to the belief that the reason the cleanup 
takes too long is because trying to cleanup 1GB memory 
of million of objects at once causes 
pool to retain all its chunks in the hope of more 
allocations in the future
which in turns causes it to waste all computation on 
running to the end of (endless) lists in the nextof 
function

I will appreciate a suggestion on how to fix this
until a more permanent solution is applied to the pool 
library

thanks
aviad
aviadr@pob.huji.ac.il

[nobody]

Logged In: NO 


If the objects are just allocated once at the beginning of the app, and then destroyed at the very end, it's a very simple memory management scenario.

Why not just create a very simple allocator that just steps along a boost::array, allocating bytes from it? The allocator would never need to reuse data so the task is a lot simpler.

Ideal would be for boost::poool to handle that, but this should get you out of trouble.

-- Matthew

[Marshall Clow]

I don't understand what the OP is talking about here:

debugging the code i noticed that the while loop in the nextof function (of SIMPLE SEGREGATED STORAGE.HPP) takes many iterations.

-- there's no loop in the nextof() function in that file. Closing.

[contact.lipik@…]

Hi, I am experiencing the exact same problem, with latest version from SVN. The while loop referred to by the OP is in simple_segregated_storage::find_prev, which is called from ordered_free. There is a comment there that this is a slow function. My app allocates around 70MB, through fast_pool_allocator based maps, as well as pool_allocator based strings/vectors. Application shutdown takes ~10 minutes. The problem disappears if I stop using pool_allocator in strings & vectors (fast_pool_allocator does not cause any issues). I'll try and attach some code to reproduce the problem tomorrow. Thanks

[fkonvick]

I also observed the problem, but there is a simple explanation. If you use MANY std::vector objects using boost::pool_allocator, then you might run into this problem. This is, AFAICT, by design - the vectors are just deallocated out of the "ideal" order. (You should not use other std containers with this allocator.)

The solution is - just use std::allocator for std::vector (the performance is comparable). For the rest, use boost::fast_pool_allocator.

(There are other solutions possible, but this is a bit OOT here.)