On Sun, Jan 18, 2009 at 4:35 AM, Nathaniel Smith <n...@pobox.com> wrote:
> On Sun, Jan 18, 2009 at 3:14 AM, Thomas Moschny <thomas.mosc...@gmx.de> > wrote: > > Derek Scherger wrote: > >> - after a reconstruction path is loaded it is scanned in forward order > >> looking for a cached roster to start from. if one is found, the > >> reconstruction path is truncated at that point and reconstruction will > >> start from the closest cached roster. > > > > Somehow I always thought the code that searches for the reconstruction > > patch would do this already: not only stop at base rosters but also at > > cached rosters - seems I was wrong. > > Err, yeah, it definitely should be doing that! And if it isn't, it > should be fixed to do that, rather than papering it over like Derek > described... > Looking at this a bit further the reconstruction path code calls is_base on the roster_reconstruction_graph which does check to see if the cache currently contains a roster to start from, so trimming the reconstruction path is probably a no-op. I have run timings on a few different things, the testsuite, db check and full pulls, with and without this change and it doesn't seem to make a lot of difference in general. I suppose db regenerate_caches might be another interesting test case although that's probably pretty similar to the client side pull. Cheers, Derek
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
