Re: [PATCH v2 3/3] connected: implement connectivity check using bitmaps

On Tue, Jun 29, 2021 at 09:51:33PM -0400, Jeff King wrote:

On Mon, Jun 28, 2021 at 07:33:15AM +0200, Patrick Steinhardt wrote:

quoted

As expected, performance doesn't change in cases where we do not have a
bitmap available given that the old code path still kicks in. In case we
do have bitmaps, this is kind of a mixed bag: while git-receive-pack(1)
is slower in a "normal" clone of linux.git, it is significantly faster
for a clone with lots of references. The slowness can potentially be
explained by the overhead of loading the bitmap. On the other hand, the
new code is faster as expected in repos which have lots of references
given that we do not have to mark all negative references anymore.

Hmm. We _do_ still have to mark those negative references now, though
(the bitmap code still considers each as a reachability tip for the
"have" side of the traversal). It's just that we may have to do less
traversal on them, if they're mentioned by other bitmaps.

So in that sense I don't think your "a ref for every commit" cases are
all that interesting. Any bitmap near the tip of history is going to
include a bit for all those old commits, because our fake set of refs
are all reachable. A much more interesting history is when you have a
bunch of little unreachable spikes coming off the main history.

This is common if you have a lot of branches in the repo, but also if
you maintain a lot of book-keeping refs (like the refs/pull/* we do at
GitHub; I assume GitLab does something similar).

Here are some real-world numbers from one of the repos that gives us
frequent problems with bitmaps. refs/pull/9937/head in this case is an
unmerged PR with 8 commits on it.

Yeah, this kind of brings us back to the old topic of pathological
performance combined with bitmaps. As I said in the cover letter, I
haven't been particularly happy with the results of this version, but
rather intended it as an RFC. Taylor's extension does look quite
interesting, but ultimately I'm not sure whether we want to use bitmaps
for connectivity checks. Your spiky-branches example neatly highlights
that it cannot really work in the general case.

I wonder where that leaves us. I'm out of ideas on how to solve this in
the general case for any push/connectivity check, so I guess that any
alternative approach would instead make use of heuristics.

In the current context, I care mostly about the user-side context, which
is interactive pushes. Without knowing the numbers, my bet is that the
most frequent usecase here is the push of a single branch with only a
bunch of commits. If the pushed commit is a descendant of any existing
commit, then we can limit the connectivity check to `git rev-list
--objects $newoid --not $oldoid` instead of `--not --all`. There's two
issues:

    - "descendant of any existing commit" is again the same territory
      performance-wise as `--all`. So we can heuristically limit this
      either to the to-be-updated-target reference if it exists, or
      HEAD.

    - Calculating ancestry can be expensive if there's too many commits
      in between or if history is unrelated. We may limit this check to
      a small number like only checking the most recent 16 commits.

If these conditions hold, then we can do above optimized check,
otherwise we fall back to the old check.

Do we actually gain anything by this? The following was executed with
linux.git and stable tags. afeb391 is an empty commit on top of master.

    Benchmark #1: git rev-list afeb391 --not --all
      Time (mean ± σ):      64.1 ms ±   8.0 ms    [User: 52.8 ms, System: 11.1 ms]
      Range (min … max):    58.2 ms …  79.5 ms    37 runs

    Benchmark #2: git rev-list afeb391 --not master
      Time (mean ± σ):       1.6 ms ±   0.5 ms    [User: 1.0 ms, System: 1.0 ms]
      Range (min … max):     0.4 ms …   2.2 ms    1678 runs

Obviously not a real-world example, but it serves as a hint that it
would help in some cases and potentially pay out quite well.

Patrick