Re: [Monotone-devel] oprofile data for mtn 0.37.

[Jack Lloyd]

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,
etc.

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
built).