From: Jeff King <peff@peff.net> To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com> Cc: Git Mailing List <git@vger.kernel.org> Subject: [PATCH 1/4] peel_ref: use faster deref_tag_noverify Date: Thu, 4 Oct 2012 03:58:15 -0400 [thread overview] Message-ID: <20121004075815.GA31325@sigill.intra.peff.net> (raw) In-Reply-To: <20121004075609.GA1355@sigill.intra.peff.net> When we are asked to peel a ref to a sha1, we internally call deref_tag, which will recursively parse each tagged object until we reach a non-tag. This has the benefit that we will verify our ability to load and parse the pointed-to object. However, there is a performance downside: we may not need to load that object at all (e.g., if we are listing peeled simply listing peeled refs), or it may be a large object that should follow a streaming code path (e.g., an annotated tag of a large blob). It makes more sense for peel_ref to choose the fast thing rather than performing the extra check, for two reasons: 1. We will already sometimes short-circuit the tag parsing in favor of a peeled entry from a packed-refs file. So we are already favoring speed in some cases, and it is not wise for a caller to rely on peel_ref to detect corruption. 2. We already silently ignore much larger corruptions, like a ref that points to a non-existent object, or a tag object that exists but is corrupted. 2. peel_ref is not the right place to check for such a database corruption. It is returning only the sha1 anyway, not the actual object. Any callers which use that sha1 to load an object will soon discover the corruption anyway, so we are really just pushing back the discovery to later in the program. Signed-off-by: Jeff King <peff@peff.net> --- This is basically bringing the optimization from 90108a2 (upload-pack: avoid parsing tag destinations, 2012-01-06) to users of peel_ref. refs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs.c b/refs.c index da74a2b..0a916a0 100644 --- a/refs.c +++ b/refs.c @@ -1225,7 +1225,7 @@ fallback: fallback: o = parse_object(base); if (o && o->type == OBJ_TAG) { - o = deref_tag(o, refname, 0); + o = deref_tag_noverify(o); if (o) { hashcpy(sha1, o->sha1); return 0; -- 1.8.0.rc0.10.g8dd2a92
next prev parent reply other threads:[~2012-10-04 22:02 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-03 12:36 upload-pack is slow with lots of refs Ævar Arnfjörð Bjarmason 2012-10-03 13:06 ` Nguyen Thai Ngoc Duy 2012-10-03 18:03 ` Jeff King 2012-10-03 18:53 ` Junio C Hamano 2012-10-03 18:55 ` Jeff King 2012-10-03 19:41 ` Shawn Pearce 2012-10-03 20:13 ` Jeff King 2012-10-04 21:52 ` Sascha Cunz 2012-10-05 0:20 ` Jeff King 2012-10-05 6:24 ` Johannes Sixt 2012-10-05 16:57 ` Shawn Pearce 2012-10-08 15:05 ` Johannes Sixt 2012-10-09 6:46 ` Shawn Pearce 2012-10-09 20:30 ` Johannes Sixt 2012-10-09 20:46 ` Johannes Sixt 2012-10-03 20:16 ` Ævar Arnfjörð Bjarmason 2012-10-03 21:20 ` Jeff King 2012-10-03 22:15 ` Ævar Arnfjörð Bjarmason 2012-10-03 23:15 ` Jeff King 2012-10-03 23:54 ` Ævar Arnfjörð Bjarmason 2012-10-04 7:56 ` [PATCH 0/4] optimizing upload-pack ref peeling Jeff King 2012-10-04 7:58 ` Jeff King [this message] 2012-10-04 18:24 ` [PATCH 1/4] peel_ref: use faster deref_tag_noverify Junio C Hamano 2012-10-04 8:00 ` [PATCH 2/4] peel_ref: do not return a null sha1 Jeff King 2012-10-04 18:32 ` Junio C Hamano 2012-10-04 8:02 ` [PATCH 3/4] peel_ref: check object type before loading Jeff King 2012-10-04 19:06 ` Junio C Hamano 2012-10-04 19:41 ` Jeff King 2012-10-04 20:41 ` Junio C Hamano 2012-10-04 21:59 ` Jeff King 2012-10-04 8:03 ` [PATCH 4/4] upload-pack: use peel_ref for ref advertisements Jeff King 2012-10-04 8:04 ` [PATCH 0/4] optimizing upload-pack ref peeling Jeff King 2012-10-04 9:01 ` Ævar Arnfjörð Bjarmason 2012-10-04 12:14 ` Nazri Ramliy 2012-10-03 22:32 ` upload-pack is slow with lots of refs Ævar Arnfjörð Bjarmason 2012-10-03 23:21 ` Jeff King 2012-10-03 23:47 ` Ævar Arnfjörð Bjarmason 2012-10-03 19:13 ` Junio C Hamano
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=20121004075815.GA31325@sigill.intra.peff.net \ --to=peff@peff.net \ --cc=avarab@gmail.com \ --cc=git@vger.kernel.org \ --subject='Re: [PATCH 1/4] peel_ref: use faster deref_tag_noverify' \ /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
Code repositories for project(s) associated with this 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).