[Botan-devel] Why Pooling_Allocator?
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;
throw Internal_Error("Pooling_Allocator: Unknown pointer was freed");
More information about the botan-devel