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

[Jack Lloyd]

On Wed, Mar 12, 2008 at 02:27:58PM -0400, Zack Weinberg wrote:
> Top of profile is
> 
> 9678874  11.1247  std::_Rb_tree<std::string, std::pair<std::string
> const, Botan::Mutex*> ...>
> 
> which I suspect is related to Botan's internal locking - Jack Lloyd,
> can you comment please?

[Cc'ing botan-devel]

Woo, good times. Yes, this is used for locking, specifically to perform
the mapping that occurs for code like

Named_Mutex_Holder lock("allocator");

Which gets and locks the mutex returned from
  global_state().get_named_mutex("allocator")

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!

Possible fixes:

1) Change this to use an enum instead of a string for indexing. Which
leaves the call count the same but should reduce the lookup costs
significantly.

2) Drop the concept entirely, use plain mutex objects where needed.

3) Drop global shared state wholesale, and require applications to
maintain any per-thread or per-process state (the RNG, allocators,
etc). [I've been leaning towards this of late for various other
reasons anyway]

4) The clever and elegant solution that you just thought of while
reading this.

I'm open to comments. In this particular case it is positive that
Monotone is following development; I am open to even wide-ranging API
changes if it offers a compelling advantage.

IIRC Monotone 0.37 uses Botan 1.5.10. I just took a quick look and I
don't have any reason to believe the numbers on that would be
particularly different with 1.7.x though I would be interested in
oprofile numbers for 0.39 so we can confirm.

-Jack