[Botan-devel] Why Pooling_Allocator?

Nathaniel Smith njs at pobox.com
Thu Oct 13 06:43:11 EDT 2005


I was running an operation a few days ago that involved outputting a
lot of RSA signatures -- ~20,000.  Still, this shouldn't take so long,
running with full optimization on a beefy box, except... they were
coming out at about 1.7 per second, or almost 0.6 seconds each.  This
is doing RSA signatures of a few hundred bytes of text, plus some
miscellaneous stuff (hashing the result, throwing it in a database,
etc.).

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.

We also were a bit confused about what the proper semantics of an
allocator are -- when is it expected to clear memory, and is it
expected to work to delete an allocator that still has live objects in
it?  Are these things documented anywhere?

Cheers,
-- Nathaniel

-- 
"Lull'd in the countless chambers of the brain,
Our thoughts are link'd by many a hidden chain:
Awake but one, and lo! what myriads rise!
Each stamps its image as the other flies"
  -- Ann Ward Radcliffe, The Mysteries of Udolpho



More information about the botan-devel mailing list