On Thu, 2008-09-04 at 09:59 -0700, Zack Weinberg wrote: > On Thu, Sep 4, 2008 at 9:28 AM, Timothy Brownawell <[EMAIL PROTECTED]> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel