Boost C++ Libraries: Ticket #290: perfomance: memory cleanup for pool takes too long

nobody — Thu, 22 Mar 2007 23:04:11 GMT

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

component, description changed; severity set

Marshall Clow — Wed, 21 Nov 2007 01:19:08 GMT

component None → pool
description modified (diff)
severity → Problem

status, resolution changed

Marshall Clow — Wed, 21 Nov 2007 22:49:16 GMT

status assigned → closed
resolution None → wontfix

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.

status changed; resolution deleted

contact.lipik@… — Tue, 29 Jan 2008 13:22:47 GMT

status closed → reopened
resolution wontfix

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

status changed; resolution set

fkonvick — Wed, 08 Apr 2009 15:37:14 GMT

status reopened → closed
resolution → invalid

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.)