From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Ben Peart <peartben@gmail.com>,
Ben Peart <benpeart@microsoft.com>,
git@vger.kernel.org, jeffhost@microsoft.com,
t.gummerer@gmail.com, mhagger@alum.mit.edu
Subject: Re: [PATCH v1] read_index_from(): Skip verification of the cache entry order to speed index loading
Date: Fri, 20 Oct 2017 10:14:08 +0900 [thread overview]
Message-ID: <xmqqh8uuipsv.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20171019160532.54teojqnhkeo2yfv@sigill.intra.peff.net> (Jeff King's message of "Thu, 19 Oct 2017 12:05:32 -0400")
Jeff King <peff@peff.net> writes:
> It should be easy enough to check that; the patch below implements it.
> I couldn't measure any speedup with it running "git ls-files >/dev/null"
> on linux.git (60k files). But nor could I get any by dropping the check
> entirely.
I would expect that the speedup (due to possible cache effect)
wouldn't be measurable if the overhead of the existing check itself
is unmeasuably not-expensive. No suprise here.
> This is mostly just a curiosity to me. For the record, I have no real
> problem with dropping this kind of on-disk data-structure validation
> when it's expensive. After all, we do not check the sort on pack .idx
> files on each run (nor pack sha1 checksums, etc) because it's too
> expensive to do so.
Yes, I agree with that stance, too. If this were expensive in the
overall picture to be measurable, I think we are OK omitting when
the index is read, especially if we make sure we are not writing out
nonsense trees out of it. Local damage to the index is very
contained as long as we do not spread breakages to trees and
commits.
next prev parent reply other threads:[~2017-10-20 1:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-18 14:27 [PATCH v1] read_index_from(): Skip verification of the cache entry order to speed index loading Ben Peart
2017-10-19 5:22 ` Junio C Hamano
2017-10-19 15:12 ` Ben Peart
2017-10-19 16:05 ` Jeff King
2017-10-20 1:14 ` Junio C Hamano [this message]
2017-10-19 22:14 ` Stefan Beller
2017-10-20 12:47 ` Johannes Schindelin
2017-10-20 18:53 ` Stefan Beller
2017-10-21 1:55 ` Junio C Hamano
2017-10-24 14:45 ` [PATCH v2] " Ben Peart
2017-10-30 12:48 ` Ben Peart
2017-10-30 18:03 ` Jeff King
2017-10-31 0:33 ` Alex Vandiver
2017-10-31 13:01 ` Ben Peart
2017-10-31 17:10 ` Jeff King
2017-11-01 6:09 ` Junio C Hamano
2017-10-31 1:49 ` Junio C Hamano
2017-10-31 12:51 ` Ben Peart
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=xmqqh8uuipsv.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=benpeart@microsoft.com \
--cc=git@vger.kernel.org \
--cc=jeffhost@microsoft.com \
--cc=mhagger@alum.mit.edu \
--cc=peartben@gmail.com \
--cc=peff@peff.net \
--cc=t.gummerer@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.