Date: 2002-11-22 13:45:11
> -----Original Message-----
> From: Alberto Barbati [mailto:abarbati_at_[hidden]]
> 1) purge_memory() does not reset the member next_size
Yes, this is in fact a bug, and it will be fixed.
> 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.
The current name will remain, for backwards compatibility. Does anyone else
want a "release_unused_memory" alias?
And it will also be updated to change next_size in a manner similar to the
way you describe.
> 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.
This should certainly be possible, and sounds reasonable; I'll look into it.
> 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?
Keeping the free list ordered allows algorithms that traverse the free list
along with the memory owned by pool to work correctly/more efficiently:
1) array allocations will be more efficient (pool_allocator keeps its free
list ordered, whereas fast_pool_allocator does not)
2) release_memory() will work correctly
3) object_pool uses the ordered property to efficiently implement the
automatic destructor calls for allocated objects