From: Jeff King <peff@peff.net>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,
"Felipe Contreras" <felipe.contreras@gmail.com>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Chris Torek" <chris.torek@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH v2 3/3] connected: implement connectivity check using bitmaps
Date: Tue, 29 Jun 2021 21:51:33 -0400 [thread overview]
Message-ID: <YNvOJQDYRWpFa+4S@coredump.intra.peff.net> (raw)
In-Reply-To: <7687dedd4722c39b5ecef2c2165147c25d16b8d9.1624858240.git.ps@pks.im>
On Mon, Jun 28, 2021 at 07:33:15AM +0200, Patrick Steinhardt wrote:
> 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.
[without bitmaps, full check but with count to suppress output]
$ time git rev-list --count refs/pull/9937/head --objects --not --all
0
real 0m1.280s
user 0m1.131s
sys 0m0.148s
[same, but with bitmaps]
$ time git rev-list --count refs/pull/9937/head --objects --not --all --use-bitmap-index
0
real 1m38.146s
user 1m30.015s
sys 0m3.443s
Yikes. Now this is a pretty extreme case, as it has a lot of bookkeeping
refs. If we limited ourselves to just the branches (in which case our
unmerged PR will appear to have a couple new commits), though, we still
get:
$ time git rev-list --count refs/pull/9937/head --objects --not --branches
64
real 0m0.366s
user 0m0.272s
sys 0m0.093s
$ time git rev-list --count refs/pull/9937/head --objects --not --branches --use-bitmap-index
61
real 0m10.372s
user 0m9.633s
sys 0m0.736s
which is still a pretty bad regression (the difference in the output is
expected; the regular traversal is not as thorough at finding objects
which appear in non-contiguous sections of history).
Again, this is one of the repositories that routinely gives us problems.
But even on git/git, which is usually not a problematic repo, I get:
$ time git rev-list refs/pull/986/head --objects --not --all
real 0m0.121s
user 0m0.024s
sys 0m0.097s
$ time git rev-list refs/pull/986/head --objects --not --all --use-bitmap-index
real 0m12.406s
user 0m5.843s
sys 0m0.734s
So even if this tradeoff might help on balance, it really makes some
cases pathologically bad.
-Peff
next prev parent reply other threads:[~2021-06-30 1:51 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 5:33 [PATCH v2 0/3] Speed up connectivity checks via bitmaps Patrick Steinhardt
2021-06-28 5:33 ` [PATCH v2 1/3] p5400: add perf tests for git-receive-pack(1) Patrick Steinhardt
2021-06-28 7:49 ` Ævar Arnfjörð Bjarmason
2021-06-29 6:18 ` Patrick Steinhardt
2021-06-29 12:09 ` Ævar Arnfjörð Bjarmason
2021-06-28 5:33 ` [PATCH v2 2/3] receive-pack: skip connectivity checks on delete-only commands Patrick Steinhardt
2021-06-28 8:00 ` Ævar Arnfjörð Bjarmason
2021-06-28 8:06 ` Ævar Arnfjörð Bjarmason
2021-06-29 6:26 ` Patrick Steinhardt
2021-06-30 1:31 ` Jeff King
2021-06-30 1:35 ` Jeff King
2021-06-30 13:52 ` Patrick Steinhardt
2021-06-28 5:33 ` [PATCH v2 3/3] connected: implement connectivity check using bitmaps Patrick Steinhardt
2021-06-28 20:23 ` Taylor Blau
2021-06-29 22:44 ` Taylor Blau
2021-06-30 2:04 ` Jeff King
2021-06-30 3:07 ` Taylor Blau
2021-06-30 5:45 ` Jeff King
2021-07-02 17:44 ` Taylor Blau
2021-07-02 21:21 ` Jeff King
2021-06-30 1:51 ` Jeff King [this message]
2021-07-20 14:26 ` Patrick Steinhardt
2021-08-02 9:37 ` [PATCH v3 0/4] Speed up connectivity checks Patrick Steinhardt
2021-08-02 9:38 ` [PATCH v3 1/4] connected: do not sort input revisions Patrick Steinhardt
2021-08-02 12:49 ` Ævar Arnfjörð Bjarmason
2021-08-03 8:50 ` Patrick Steinhardt
2021-08-04 11:01 ` Ævar Arnfjörð Bjarmason
2021-08-02 19:00 ` Junio C Hamano
2021-08-03 8:55 ` Patrick Steinhardt
2021-08-03 21:47 ` Junio C Hamano
2021-08-02 9:38 ` [PATCH v3 2/4] revision: stop retrieving reference twice Patrick Steinhardt
2021-08-02 12:53 ` Ævar Arnfjörð Bjarmason
2021-08-02 9:38 ` [PATCH v3 3/4] revision: avoid loading object headers multiple times Patrick Steinhardt
2021-08-02 12:55 ` Ævar Arnfjörð Bjarmason
2021-08-05 10:12 ` Patrick Steinhardt
2021-08-02 19:40 ` Junio C Hamano
2021-08-03 9:07 ` Patrick Steinhardt
2021-08-06 14:17 ` Patrick Steinhardt
2021-08-02 9:38 ` [PATCH v3 4/4] revision: avoid hitting packfiles when commits are in commit-graph Patrick Steinhardt
2021-08-02 20:01 ` Junio C Hamano
2021-08-03 9:16 ` Patrick Steinhardt
2021-08-03 21:56 ` Junio C Hamano
2021-08-05 11:01 ` Patrick Steinhardt
2021-08-05 16:16 ` Junio C Hamano
2021-08-04 10:51 ` Ævar Arnfjörð Bjarmason
2021-08-05 11:25 ` [PATCH v4 0/6] Speed up connectivity checks Patrick Steinhardt
2021-08-05 11:25 ` [PATCH v4 1/6] revision: separate walk and unsorted flags Patrick Steinhardt
2021-08-05 18:47 ` Junio C Hamano
2021-08-05 11:25 ` [PATCH v4 2/6] connected: do not sort input revisions Patrick Steinhardt
2021-08-05 18:44 ` Junio C Hamano
2021-08-06 6:00 ` Patrick Steinhardt
2021-08-06 16:50 ` Junio C Hamano
2021-08-05 11:25 ` [PATCH v4 3/6] revision: stop retrieving reference twice Patrick Steinhardt
2021-08-05 11:25 ` [PATCH v4 4/6] revision: avoid loading object headers multiple times Patrick Steinhardt
2021-08-05 11:25 ` [PATCH v4 5/6] commit-graph: split out function to search commit position Patrick Steinhardt
2021-08-05 11:25 ` [PATCH v4 6/6] revision: avoid hitting packfiles when commits are in commit-graph Patrick Steinhardt
2021-08-09 8:00 ` [PATCH v5 0/5] Speed up connectivity checks Patrick Steinhardt
2021-08-09 8:02 ` Patrick Steinhardt
2021-08-09 8:11 ` Patrick Steinhardt
2021-08-09 8:11 ` [PATCH v5 1/5] revision: separate walk and unsorted flags Patrick Steinhardt
2021-08-09 8:11 ` [PATCH v5 2/5] connected: do not sort input revisions Patrick Steinhardt
2021-08-09 8:11 ` [PATCH v5 3/5] revision: stop retrieving reference twice Patrick Steinhardt
2021-08-09 8:11 ` [PATCH v5 4/5] commit-graph: split out function to search commit position Patrick Steinhardt
2021-08-09 8:12 ` [PATCH v5 5/5] revision: avoid hitting packfiles when commits are in commit-graph Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YNvOJQDYRWpFa+4S@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=chris.torek@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ps@pks.im \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).