[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Performance Issues With Version 0.40
From: |
Timothy Brownawell |
Subject: |
Re: [Monotone-devel] Performance Issues With Version 0.40 |
Date: |
Thu, 04 Sep 2008 17:35:21 +0000 |
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
Re: [Monotone-devel] Performance Issues With Version 0.40, aecooper, 2008/09/05