> On Jan 19, 2018, at 16:35, Boris Feld <boris.f...@octobus.net> wrote: > > On Fri, 2018-01-19 at 15:54 -0500, Augie Fackler wrote: >> On Fri, Jan 19, 2018 at 09:08:48PM +0100, Boris Feld wrote: >>> # HG changeset patch >>> # User Boris Feld <boris.f...@octobus.net> >>> # Date 1516232936 -3600 >>> # Thu Jan 18 00:48:56 2018 +0100 >>> # Node ID 4ee91fb55e208e8b139595ce9c2cae25aa9c54ea >>> # Parent b80a8e39ac9bf984c25a666bd7f6c47d876d26af >>> # EXP-Topic b2-stream >>> # Available At https://bitbucket.org/octobus/mercurial-devel/ >>> # hg pull https://bitbucket.org/octobus/mercurial-deve >>> l/ -r 4ee91fb55e20 >>> streamclone: define first iteration of version 2 of stream format >> >> This is a good start of a series, but: >> >> 1) patch 3 is begging for doctests on the varint scheme >> > > We are about to follow up with them.
Just hold them for 4.6 please. > >> 2) This patch should probably include help/internals/ documentation >> on >> the format, rather than only encoding it in a docstring >> > > We can follow up with that. > >> 3) Patches that claim to be a big performance win, but don't include >> any concrete testing numbers. > > The performance win is about recomputing cache. We are getting number > as we speak, but performance issue related to branchmap and tags have > been well documented in the past. You're mostly missing the point: the reason for this significant body of new functionality was performance wins. I'd expect patches that come in under a performance banner to explain, including with benchmarks why they're a win. In this case, that includes not only explaining that we avoid a 25 minute cache hit (which is great), but also some testing that demonstrates that the new format is at least *not worse* than what was there before. bundle2 doesn't have a spotless performance record, so I get reflexively dubious when a new format inside bundle2 claims to be a win. :) > On our repository with the most heads, it took 25 minutes to recompute > the tags cache and 1 minute for the branch cache. And the laptop wasn't > doing much else. > >> >> I think at this point we're going to admit defeat in the name of >> getting an RC release done before I go to bed tonight. Performance >> information I'd like to see in any v3 of this series: >> >> 1) comparison between the new streaming clone and the existing one on >> small repos >> >> 2) comparison on a medium repo with few branches (the hg repo could >> be good for this) >> >> 3) comparison on a large repo with many heads (might need to use >> contrib/synthrepo to make something for this?) >> >> 4) comparison on a large repo with many named branches (pypy?) >> >> 5) comparison on mozilla-central > > Those characteristics shouldn't impact the performance of the stream > clone. It's more about relative overheads and things. My gut is that involving bundle2 adds measurable overhead to the process (though I could be wrong!), so I'd like a decent spectrum of repo types to try and help figure out how much the cache recomputation is a win or not. Does that make sense? Anyway, it's too late for this cycle, as I'm about out of time in my day to make a release. Sorry. :/ _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
