Re: [Monotone-devel] Performance Issues With Version 0.40

[Timothy Brownawell]

On Thu, 2008-09-04 at 09:59 -0700, Zack Weinberg wrote:
> On Thu, Sep 4, 2008 at 9:28 AM, Timothy Brownawell <address@hidden> wrote:
> > Running lots (500) of get_content_changed commands thru automate stdio,
> > it seems to be around 1 1/2 times slower here. There's about a 46%
> > speedup from hand-coding decode_hexenc (instead of using Botan),
> 
> We should probably just go ahead and do that, but I'd like to know
> what things we still have to decode_hexenc - the 0.40 database changes
> ought to have meant we need to do that way less often.

roster_t::parse_from() and parse_marking(). Try "mtn get_roster" in any
workspace and look at all the pretty hex strings :)

> > about
> > 38% from making the db variable in the get_content_changed command
> > static (I think most of this is because initializing the db each time
> > includes verifying the schema each time),
> 
> Oh, ick.
> 
> A cleaner approach would probably be to cache the sqlite handle in the
> app_state.  I didn't want to go there initially because I was planning
> on doing the ro/rw_database distinction that might need to close and
> reopen sqlite handles to get the effect we want, but since I don't
> have time to do that anytime soon, perhaps we should do the caching
> anyway.

Or just keep a shared_ptr to the database_impl (or probably a map to
allow lookup based on filename, wasn't part of the reason for splitting
db out from app_state to allow for multiple dbs in the future?).

database currently uses a scoped_ptr instead of a shared_ptr, is there
some deep reason about not wanting to allow database_impl's to be shared
or is it just because they didn't need to be shared?

-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net