Boost logo

Boost :

From: Alberto Barbati (abarbati_at_[hidden])
Date: 2002-11-21 17:24:22


Hi Everybody,

I recently used library boost::pool, it's a very nice library and
extremely useful. I would like to submit a few requests and ask one
question about it.

1) purge_memory() does not reset the member next_size, but in my opinion
it should. The rationale is that after a purge_memory() the pool should
be in the exact state it was at the moment of construction. For example,
in an application of mine, I have a long life pool object (in fact a
singleton_pool) that is emptied with purge_memory() from time to time.
The first allocation after purge_memory() allocates a block of size
next_size, then multiplies next_size by 2. As the next_size is never
reset, it grows exponentially. Imagine my face when I found that
allocating a 12 byte object from an empty pool required more than 1Gb...

2) the name release_memory() confuses me. It makes me think that all
memory is being released, a task accomplished by purge_memory(). I think
a better name could be release_unused_memory(). This function also
should reduce the value of next_size, for example by considering the
size of the largest block left in the pool.

3) I would like to have a function to free the entire pool _without_
releasing the memory. The rationale for this is in the example above.
Most probably, the number of objects allocated in each iteration of my
application is almost the same. At the end of an iteration, I would like
to free all allocated objects with one single call (as I have thousands
of objects, it makes the difference) yet it's a waste of time to free
the memory, because I will need the same amount again in the next
iteration. Such function could be called free_all_chunks() or something
similar.

4) what's the use of ordered_alloc/ordered_free? I made a few tests and
they are indeed a bit slower than regular alloc/free, without any
apparent advantage. Am I missing something?

Thanks in advance,

Alberto Barbati


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk