[Botan-devel] Why Pooling_Allocator?

Jack Lloyd lloyd at randombit.net
Thu Oct 13 11:09:55 EDT 2005


On Thu, Oct 13, 2005 at 08:25:39PM +0800, Matt Johnston wrote:

> I've had a look at this, and I think that the problem lies
> in the exit path of Pooling_Allocator::free_block().  Via
> std::cerr debugging, it appears that real_mem keeps filling
> up with zero length buffers (which have been
> dealloc_block()ed and zeroed), which never get removed from
> the list. This leads to all of the other iterations over
> real_mem being _very_ slow. I've yet to pin down a concise
> testcase to trigger this though.

Interesting! Nice catch. I'm going to take a look at this as well, this should
definitely not be happening - the whole point of remove_empty_buffers is to
remove those empty blocks. Your patch looks fine from a correctness standpoint,
but moving the call there should (in theory) hurt, not help, performance, so
something is obviously broken.

By the way, Matt and Nathaniel, I want to apologize to both of you. That code
is rather convoluted and hard to follow, and I should have documented it much
better.

-Jack



More information about the botan-devel mailing list