From: Jeff King <firstname.lastname@example.org> To: "Ævar Arnfjörð Bjarmason" <email@example.com> Cc: Git Mailing List <firstname.lastname@example.org> Subject: [PATCH 0/4] optimizing upload-pack ref peeling Date: Thu, 4 Oct 2012 03:56:09 -0400 [thread overview] Message-ID: <20121004075609.GA1355@sigill.intra.peff.net> (raw) In-Reply-To: <CACBZZX5Sm++Wjyoue-qk7TjwxUM3QihXfWGtEHhOq=VtkgvNbQ@mail.gmail.com> On Thu, Oct 04, 2012 at 01:54:47AM +0200, Ævar Arnfjörð Bjarmason wrote: > > Hmm. It seems like we should not need to open the tags at all. The main > > reason is to produce the "peeled" advertisement just after it. But for a > > packed ref with a modern version of git that supports the "peeled" > > extension, we should already have that information. > > B.t.w. do you plan to submit this as a non-hack, I'd like to have it > in git.git, so if you're not going to I could pick it up and clean it > up a bit. But I think it would be better coming from you. Here's a cleaned-up version. I realized that peel_ref actually is quite close to what we want; the key thing is that when you are calling it from a for_each_ref loop it will not only use peeled information from packed-refs (if available), but it will also short-circuit the ref lookup for non-packed refs. So it really does what we want. I put some timings into the final patch. The results are very satisfying from a pure numbers standpoint. However, I'm not 100% sure this is all that useful a benchmark. The repos where you get a noticeable benefit are quite big, so I suspect the time to send the advertisements out over the wire will dominate. Still, a CPU second saved is a CPU second earned. And the series actually ends up making the code cleaner and shares some of the optimizations I put into upload-pack with other users of peel_ref. So I think I'd be inclined to use it, even if the speedup doesn't help that much in practice. We'll see what others think. [1/4]: peel_ref: use faster deref_tag_noverify [2/4]: peel_ref: do not return a null sha1 [3/4]: peel_ref: check object type before loading [4/4]: upload-pack: use peel_ref for ref advertisements -Peff
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 ` Jeff King [this message] 2012-10-04 7:58 ` [PATCH 1/4] peel_ref: use faster deref_tag_noverify Jeff King 2012-10-04 18:24 ` 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=20121004075609.GA1355@sigill.intra.peff.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 0/4] optimizing upload-pack ref peeling' \ /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).