From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, "Jeff King" <peff@peff.net>,
"Felipe Contreras" <felipe.contreras@gmail.com>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Chris Torek" <chris.torek@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH v2 2/3] receive-pack: skip connectivity checks on delete-only commands
Date: Mon, 28 Jun 2021 10:06:09 +0200 [thread overview]
Message-ID: <87v95ywgx8.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <87y2auwh1d.fsf@evledraar.gmail.com>
On Mon, Jun 28 2021, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Jun 28 2021, Patrick Steinhardt wrote:
>
>> [[PGP Signed Part:Undecided]]
>> In the case where git-receive-pack(1) receives only commands which
>> delete references, then per technical specification the client MUST NOT
>> send a packfile. As a result, we know that no new objects have been
>> received, which makes it a moot point to check whether all received
>> objects are fully connected.
>
> Is it just per specification, or do we also have assertions/tests for
> what happens in that case?
>
>> [...]
>> The following tests were executed on linux.git and back up above
>> expectation:
>>
>> Test origin/master HEAD
>> ---------------------------------------------------------------------------------------------------------
>> 5400.4: empty receive-pack updated:new 178.36(428.22+164.36) 177.62(421.33+164.48) -0.4%
>> 5400.7: clone receive-pack updated:new 0.10(0.08+0.02) 0.10(0.08+0.02) +0.0%
>> 5400.9: clone receive-pack updated:main 0.10(0.08+0.02) 0.11(0.08+0.02) +10.0%
>> 5400.11: clone receive-pack main~10:main 0.15(0.11+0.04) 0.15(0.10+0.05) +0.0%
>> 5400.13: clone receive-pack :main 0.01(0.00+0.01) 0.01(0.01+0.00) +0.0%
>> 5400.16: clone_bitmap receive-pack updated:new 0.10(0.07+0.02) 0.09(0.06+0.02) -10.0%
>> 5400.18: clone_bitmap receive-pack updated:main 0.10(0.07+0.02) 0.10(0.08+0.02) +0.0%
>> 5400.20: clone_bitmap receive-pack main~10:main 0.15(0.11+0.03) 0.15(0.12+0.03) +0.0%
>> 5400.22: clone_bitmap receive-pack :main 0.02(0.01+0.01) 0.01(0.00+0.00) -50.0%
>> 5400.25: extrarefs receive-pack updated:new 32.34(20.72+11.86) 32.56(20.82+11.95) +0.7%
>> 5400.27: extrarefs receive-pack updated:main 32.42(21.02+11.61) 32.52(20.64+12.10) +0.3%
>> 5400.29: extrarefs receive-pack main~10:main 32.53(20.74+12.01) 32.39(20.63+11.97) -0.4%
>> 5400.31: extrarefs receive-pack :main 7.13(3.53+3.59) 7.15(3.80+3.34) +0.3%
>> 5400.34: extrarefs_bitmap receive-pack updated:new 32.55(20.72+12.04) 32.65(20.68+12.18) +0.3%
>> 5400.36: extrarefs_bitmap receive-pack updated:main 32.50(20.90+11.86) 32.67(20.93+11.94) +0.5%
>> 5400.38: extrarefs_bitmap receive-pack main~10:main 32.43(20.88+11.75) 32.35(20.68+11.89) -0.2%
>> 5400.40: extrarefs_bitmap receive-pack :main 7.21(3.58+3.63) 7.18(3.61+3.57) -0.4%
>
> We're doing less work so I'd expect to te be faster, but do these tests
> really back that up? From eyeballing these I can't find a line where the
> confidence intervals don't overlap, e.g. the +10% regresison is a
> .10->.11 "regression" with a [+-] 0.02 (so within the error bars) etc,
> ditto for the -50% improvement.
>
> Perhaps the error bars will reduce with a high GIT_PERF_REPEAT_COUNT, or
> the re-arrangement for keeping things hotter in cache that I suggested
> in 1/3.
Urgh, nevermind. Just after I sent this I re-read t/perf/README. I'd
somehow recalled that we'd emit error bars from it, but that's
Elapsed(User + System), not Time(.. + errorbar) as I thought, nevermind.
Still, numbers are such that I wonder if the differences are getting
lost in some noise...
next prev parent reply other threads:[~2021-06-28 8:07 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v95ywgx8.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=chris.torek@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.