From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Derrick Stolee <dstolee@microsoft.com>
Cc: git@vger.kernel.org, git@jeffhostetler.com, sbeller@google.com
Subject: Re: [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r
Date: Tue, 3 Oct 2017 07:26:02 -0400 [thread overview]
Message-ID: <6a3804a4-9728-d122-7fac-f297fc7977d1@gmail.com> (raw)
In-Reply-To: <xmqqinfwh5g0.fsf@gitster.mtv.corp.google.com>
On 10/3/2017 6:49 AM, Junio C Hamano wrote:
> Derrick Stolee <dstolee@microsoft.com> writes:
>
>> p0008.1: find_unique_abbrev() for existing objects
>> --------------------------------------------------
>>
>> For 10 repeated tests, each checking 100,000 known objects, we find the
>> following results when running in a Linux VM:
>>
>> | | Pack | Packed | Loose | Base | New | |
>> | Repo | Files | Objects | Objects| Time | Time | Rel% |
>> |-------|-------|---------|--------|--------|--------|---------|
>> | Git | 1 | 230078 | 0 | 0.09 s | 0.06 s | - 33.3% |
>> | Git | 5 | 230162 | 0 | 0.11 s | 0.08 s | - 27.3% |
>> | Git | 4 | 154310 | 75852 | 0.09 s | 0.07 s | - 22.2% |
>> | Linux | 1 | 5606645 | 0 | 0.12 s | 0.32 s | +146.2% |
>> | Linux | 24 | 5606645 | 0 | 1.12 s | 1.12 s | - 0.9% |
>> | Linux | 23 | 5283204 | 323441 | 1.08 s | 1.05 s | - 2.8% |
>> | VSTS | 1 | 4355923 | 0 | 0.12 s | 0.23 s | + 91.7% |
>> | VSTS | 32 | 4355923 | 0 | 1.02 s | 1.08 s | + 5.9% |
>> | VSTS | 31 | 4276829 | 79094 | 2.25 s | 2.08 s | - 7.6% |
> The above does not look so good, especially in cases where a
> repository is well maintained by packing into smaller number of
> packs, we get much worse result?
I understand that this patch on its own does not have good numbers. I
split the
patches 3 and 4 specifically to highlight two distinct changes:
Patch 3: Unroll the len loop that may inspect all files multiple times.
Patch 4: Parse less while disambiguating.
Patch 4 more than makes up for the performance hits in this patch.
>
>> p0008.2: find_unique_abbrev() for missing objects
>> -------------------------------------------------
>>
>> For 10 repeated tests, each checking 100,000 missing objects, we find
>> the following results when running in a Linux VM:
>>
>> | | Pack | Packed | Loose | Base | New | |
>> | Repo | Files | Objects | Objects| Time | Time | Rel% |
>> |-------|-------|---------|--------|--------|--------|--------|
>> | Git | 1 | 230078 | 0 | 0.66 s | 0.08 s | -87.9% |
>> | Git | 5 | 230162 | 0 | 0.90 s | 0.13 s | -85.6% |
>> | Git | 4 | 154310 | 75852 | 0.79 s | 0.10 s | -87.3% |
>> | Linux | 1 | 5606645 | 0 | 0.48 s | 0.32 s | -33.3% |
>> | Linux | 24 | 5606645 | 0 | 4.41 s | 1.09 s | -75.3% |
>> | Linux | 23 | 5283204 | 323441 | 4.11 s | 0.99 s | -75.9% |
>> | VSTS | 1 | 4355923 | 0 | 0.46 s | 0.25 s | -45.7% |
>> | VSTS | 32 | 4355923 | 0 | 5.40 s | 1.15 s | -78.7% |
>> | VSTS | 31 | 4276829 | 79094 | 5.88 s | 1.18 s | -79.9% |
> The question is if this is even measuring a relevant workload. How
> often would we have a full 40-hex object name for which we actually
> do not have the object, and ask its name to be abbreviated?
>
> Compared to it, the result from p0008.1 feels a lot more important.
> We know we make tons of "abbreviate the object name for this object
> we have" and we see them every day in our "git log -p" output.
>
> Seeing a lot more impressive result from p0008.2 than p0008.1 makes
> me unsure if this patch is optimizing for the right case.
>
> I'll have to see the code a bit deeper before I can comment on it.
>
> Thanks.
I agree that p0008.1 is more important. p0008.2 covers an important case
of the
previous implementation. The line
exists = has_sha1_file(sha1);
will inspect all packfiles and scan the full loose-object directory that
would contain
the object. The only reason for this call is to determine how to inspect
the result of
get_short_oid(), but is a significant portion of the time that is gained
here.
Thanks,
-Stolee
next prev parent reply other threads:[~2017-10-03 11:26 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-25 9:54 [PATCH v2 0/5] Improve abbreviation disambiguation Derrick Stolee
2017-09-25 9:54 ` [PATCH v2 1/5] test-list-objects: List a subset of object ids Derrick Stolee
2017-09-26 9:24 ` Junio C Hamano
2017-10-05 8:42 ` Jeff King
2017-10-05 9:48 ` Junio C Hamano
2017-10-05 10:00 ` Jeff King
2017-10-05 10:16 ` Junio C Hamano
2017-10-05 12:39 ` Derrick Stolee
2017-10-06 14:11 ` Jeff King
2017-10-07 19:12 ` Derrick Stolee
2017-10-07 19:33 ` Jeff King
2017-10-08 1:46 ` Junio C Hamano
2017-09-25 9:54 ` [PATCH v2 2/5] p0008-abbrev.sh: Test find_unique_abbrev() perf Derrick Stolee
2017-09-26 9:27 ` Junio C Hamano
2017-10-05 8:55 ` Jeff King
2017-10-05 8:57 ` Jeff King
2017-09-25 9:54 ` [PATCH v2 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r Derrick Stolee
2017-09-25 9:54 ` [PATCH v2 4/5] sha1_name: Parse less while finding common prefix Derrick Stolee
2017-09-25 23:42 ` Stefan Beller
2017-10-02 14:52 ` Derrick Stolee
2017-09-25 9:54 ` [PATCH v2 5/5] sha1_name: Minimize OID comparisons during disambiguation Derrick Stolee
2017-10-02 14:56 ` [PATCH v3 0/5] Improve abbreviation disambituation Derrick Stolee
2017-10-05 9:49 ` Jeff King
2017-10-02 14:56 ` [PATCH v3 1/5] test-list-objects: List a subset of object ids Derrick Stolee
2017-10-03 4:16 ` Junio C Hamano
2017-10-02 14:56 ` [PATCH v3 2/5] p0008-abbrev.sh: Test find_unique_abbrev() perf Derrick Stolee
2017-10-02 14:56 ` [PATCH v3 3/5] sha1_name: Unroll len loop in find_unique_abbrev_r Derrick Stolee
2017-10-03 10:49 ` Junio C Hamano
2017-10-03 11:26 ` Derrick Stolee [this message]
2017-10-04 6:10 ` Junio C Hamano
2017-10-04 13:06 ` Derrick Stolee
2017-10-04 6:07 ` Junio C Hamano
2017-10-04 13:19 ` Derrick Stolee
2017-10-05 1:26 ` Junio C Hamano
2017-10-05 9:13 ` Jeff King
2017-10-05 9:50 ` Junio C Hamano
2017-10-02 14:56 ` [PATCH v3 4/5] sha1_name: Parse less while finding common prefix Derrick Stolee
2017-10-04 6:14 ` Junio C Hamano
2017-10-02 14:56 ` [PATCH v3 5/5] sha1_name: Minimize OID comparisons during disambiguation Derrick Stolee
2017-10-03 15:55 ` Stefan Beller
2017-10-03 17:05 ` Derrick Stolee
2017-10-05 9:44 ` Jeff King
2017-10-06 13:52 ` [PATCH] cleanup: fix possible overflow errors in binary search Derrick Stolee
2017-10-06 14:18 ` Jeff King
2017-10-06 14:41 ` Derrick Stolee
2017-10-08 18:29 ` [PATCH v2] " Derrick Stolee
2017-10-09 13:33 ` Jeff King
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=6a3804a4-9728-d122-7fac-f297fc7977d1@gmail.com \
--to=stolee@gmail.com \
--cc=dstolee@microsoft.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sbeller@google.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).