[Botan-devel] Re: [Monotone-devel] oprofile data for mtn 0.37.
lloyd at randombit.net
Wed Mar 12 17:46:37 EDT 2008
On Wed, Mar 12, 2008 at 05:19:50PM -0400, Zack Weinberg wrote:
> > I'm pretty surprised it is that high though (both in call counts, and
> > b/c generally where it is called something else that is expensive is
> > going on). But clearly no matter what the circumstances this is not
> > ideal!
> It occurs to me that we (monotone) create and destroy one Botan::Pipe
> and at least one subclass of Botan::Filter for every call to most of
> the functions in transform.hh. If there's a global lock around
> allocating the memory for that, that could explain it.
Yup. At least one and actually probably several. I should probably explain
what is going on here a little further:
Each memory block (eg SecureVector) when constructed gets a reference
to an allocator object. Doing so involves going into the shared state
object in libstate.cpp to pull it out. A Pipe/Filter is going to
involve (at least) a couple of these for processing, output buffers,
Actually allocating memory is not (in 1.7.3/1.7.4) going to cause
locking as the default allocator is basically fastpathed to malloc().
(It does invoke locks if it goes into the pool code in Botan).
> [Is it practical to bypass the Pipe interface and manipulate
> e.g. Hex_Encoder directly?]
Not really, no. (It should be, but it is not; and doing so would
require a major revamp/rethink of how the whole filter interface is
More information about the botan-devel