[Botan-devel] Why Pooling_Allocator?
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,
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?
"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