[Botan-devel] Why Pooling_Allocator?

Matt Johnston matt at ucc.asn.au
Thu Oct 13 08:25:39 EDT 2005

On Thu, Oct 13, 2005 at 03:43:11AM -0700, Nathaniel Smith wrote:
> Profiling showed that the problem was that our code was spending >96%
> of all CPU time in Pooling_Allocator::deallocate.  Unsurprisingly,
> swapping in a trivial allocator implementation that simply deferred to
> malloc() and free() gave a huge improvement in performance -- about a
> factor of 25x overall throughput.
> So, we're working on finding a minimal test case for this, but, in the
> mean time... can anyone explain _why_ this strange Pool_Allocator
> class exists?  I'm just not sure why we wouldn't simply defer to
> the system's highly-optimized malloc, and this confusion makes it hard
> to know what a proper fix would look like.

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.

The attached patch improves performance considerably, though
I'm only guessing as to when remove_empty_buffers() is meant
to be called.

-------------- next part --------------
# old_revision [62d994d89e706edaeef357e15047802c0942a4b2]
# patch "botan/mem_pool.cpp"
#  from [cc72eb332ab2c10e96d65332b22dec4d46fc5621]
#    to [5deff590833f7d17b332f12a417a7b4e1cf91beb]
--- botan/mem_pool.cpp	cc72eb332ab2c10e96d65332b22dec4d46fc5621
+++ botan/mem_pool.cpp	5deff590833f7d17b332f12a417a7b4e1cf91beb
@@ -268,10 +268,10 @@
             real_mem[j].in_use = false;
+         remove_empty_buffers(real_mem);
-   remove_empty_buffers(real_mem);
    throw Internal_Error("Pooling_Allocator: Unknown pointer was freed");

More information about the botan-devel mailing list