discovery: clarify why the caching of children is valid Yuya Nishihara pointed out that the code looks wrong without this clarification. (And, unsurprisingly, Yuya is right)

tests: clarify test setup test in test-uncommit.t I assume the "hg uncommit b" is there to prove that the working copy is dirty before we try "hg uncommit --allow-dirty-working-copy b". It seems clearer to put that check just before we run the actual test. Differential Revision: https://phab.mercurial-scm.org/D6078

tests: fix a stale reference to experimental.uncommitondirtywdir These tests no longer test the config option, they test the command line flag. Differential Revision: https://phab.mercurial-scm.org/D6077

discovery: explicitly use `undecided` for the children mapping Recent performance achievements makes the assumption that the `undecided` set is used for sampling. That assumption is always true in practice. We stop pretending that taking anything else would make sense and we directly use the `undecided` set from the object. This provides a more honest API.

discovery: cache the children mapping used during each discovery During discovery, the `undecided` set keep shrinking. Therefore, the map computed for an iteration N will be valid for iteration N+1. Instead of computing the same data over and over we cache it the first time. Our private pathological case speed up from about 7.5 seconds to about 6.3 seconds. (starting from over 70s at the start of the full series)

discovery: move children computation in its own method This clarifies the main logic and starts to pave the way to some caching.

discovery: simplify the building of the children mapping Since we only care about the revisions inside the set we are sampling, we can use simpler code (and probably sightly faster).

discovery: simply walk the undecided revs when building the children mapping The sampling only care about revisions in the undecided set, so building children relationship within this set is sufficient. The set of undecided changesets can be much smaller than the full span from its smallest item to the tip of the repository. This restriction can significantly speed up operations in some cases. For example, on our private pathological case, this speeds things up from about 53 seconds to about 7.5 seconds.

discovery: use a lower level but faster way to retrieve parents We already know that no revision in the undecided set are filtered, so we can skip multiple checks and directly access lower level data. In a private pathological case, this improves the timing from about 70 seconds to about 50 seconds. There are other actions to be taken to improve that case, however this gives an idea of the general overhead.

discovery: avoid computing identical sets of heads twice The very same set of heads is computed in the previous statement, it seems more efficient to just copy that result.