[PATCH] discovery: be more conservative when adjusting the sample size

[Martin von Zweigbergk]

On Wed, Jun 5, 2019 at 8:16 AM Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 6/5/19 3:21 PM, Martin von Zweigbergk wrote:
> >
> >
> > On Wed, Jun 5, 2019, 03:36 Pierre-Yves David
> > <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
>
> > wrote:
> >
> >     # HG changeset patch
> >     # User Pierre-Yves David <pierre-yves.david at octobus.net
> >     <mailto:pierre-yves.david at octobus.net>>
> >     # Date 1559726605 -7200
> >     #      Wed Jun 05 11:23:25 2019 +0200
> >     # Node ID 2c67430451fafcdd68770436c520e2d008428986
> >     # Parent  12793787439538411013edffe0f9b98762d38a37
> >     # EXP-Topic discovery-large-undecided
> >     # Available At https://bitbucket.org/octobus/mercurial-devel/
> >     #              hg pull
> >     https://bitbucket.org/octobus/mercurial-devel/ -r 2c67430451fa
> >     discovery: be more conservative when adjusting the sample size
> >
> >     Since 5b34972a0094, the discovery will increase the sample size when
> >     it detect a
> >     "complex" undecided set. However this detection focussed on the
> >     number of roots
> >     only, this could regress discovery performance when the undecided
> >     set has many
> >     roots that eventually get merged into a few heads.
> >
> >
> > Seems unlikely to happen in practice. That's why I didn't bother with it
> > in my patch.
>
> There are very common use case where this happens (eg: many feature
> branch eventually merged into one head for integration testing).
>

Right, that's the example I gave. I didn't mean that it seems unlikely that
there are fewer heads than roots, only that it seems unlikely that there's
a significant difference between them.


> > Also, the performance regression you're talking about is on slow
> > networks, right? I.e., it's not that more round trips or more CPU would
> > be required; the concern is rather that it takes time to transfer the
> > nodeids on slow networks, right?
>
> I am concern about suddenly sending much more information in case where
> we did not before and it would not help the discovery. Both in term of
> bandwidth and processing on the server side.
>
> > So if you have some CI system that merges 100k heads into one in order
> > to tests all proposed changes together, and it's on slow network, it
> > would benefit from this patch?
>
> The idea behind this patch is to adjust the code to be more in the
> spirit of the initial patch. If we want to try and cheaply adjust
> behavior for situation where there are probably many disconnected set
> while keeping the existing behavior for large connected set.
> This patch make a small change to better detect case of large connected
> set. If there are few heads or few roots there cannot be many
> disconnected set.
>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190605/5cb96bcf/attachment.html>