git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] pack-objects: optimize "recency order"
Date: Fri, 08 Jul 2011 15:47:23 -0700	[thread overview]
Message-ID: <7vfwmgfkzo.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1310084657-16790-3-git-send-email-gitster@pobox.com> (Junio C. Hamano's message of "Thu, 7 Jul 2011 17:24:17 -0700")

This updates the codepath to write commit objects so that when a commit is
emitted, its parents are scheduled to be output next (but this does not go
recursively), in the hope that it may help a typical "rev-list" traversal.

I've tried various workloads from the previous message; while this patch
does not regress any of them significantly, it does not seem to improve
them significantly, either.



 builtin/pack-objects.c |   96 ++++++++++++++++++++++++++++++++++-------------
 1 files changed, 69 insertions(+), 27 deletions(-)

diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 27132bb..46ae610 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -487,6 +487,74 @@ static void add_family_to_write_order(struct object_entry **wo,
 	add_descendants_to_write_order(wo, endp, root);
 }
 
+static void add_commit_to_write_order(struct object_entry **wo,
+				      int *endp,
+				      struct object_entry *e)
+{
+	/*
+	 * A typical rev-list traversal looks at the parent of a
+	 * commit before deciding to emit the commit; if it ends up
+	 * emitting this commit, it is likely that it needs an early
+	 * access of its parents.
+	 */
+	struct commit *commit;
+	struct commit_list *parents;
+
+	if (e->filled)
+		return;
+	add_to_write_order(wo, endp, e);
+	commit = lookup_commit(e->idx.sha1);
+	if (!commit ||
+	    (!commit->object.parsed && parse_commit(commit)))
+		die("BUG: calling add_commit with a non-commit???");
+	for (parents = commit->parents; parents; parents = parents->next) {
+		struct object_entry *pe;
+		struct commit *parent = parents->item;
+		pe = locate_object_entry(parent->object.sha1);
+		if (pe)
+			add_to_write_order(wo, endp, pe);
+	}
+}
+
+static int add_commits_to_write_order(struct object_entry **wo)
+{
+	int i, wo_end;
+
+	/*
+	 * Give the commits in the original recency order until
+	 * we see a tagged tip.
+	 */
+	for (i = wo_end = 0; i < nr_objects; i++) {
+		if (objects[i].type != OBJ_COMMIT)
+			continue;
+		if (objects[i].tagged)
+			break;
+		add_commit_to_write_order(wo, &wo_end, &objects[i]);
+	}
+
+	/*
+	 * Then fill all the tagged tips.
+	 */
+	for (i = 0; i < nr_objects; i++) {
+		if (objects[i].type != OBJ_COMMIT)
+			continue;
+		if (objects[i].tagged)
+			add_commit_to_write_order(wo, &wo_end, &objects[i]);
+	}
+
+	/*
+	 * And then all remaining commits and tags.
+	 */
+	for (i = 0; i < nr_objects; i++) {
+		if (objects[i].type == OBJ_COMMIT)
+			add_commit_to_write_order(wo, &wo_end, &objects[i]);
+		else if (objects[i].type != OBJ_TAG)
+			add_to_write_order(wo, &wo_end, &objects[i]);
+	}
+
+	return wo_end;
+}
+
 static struct object_entry **compute_write_order(void)
 {
 	int i, wo_end;
@@ -519,33 +587,7 @@ static struct object_entry **compute_write_order(void)
 	 */
 	for_each_tag_ref(mark_tagged, NULL);
 
-	/*
-	 * Give the commits in the original recency order until
-	 * we see a tagged tip.
-	 */
-	for (i = wo_end = 0; i < nr_objects; i++) {
-		if (objects[i].tagged)
-			break;
-		add_to_write_order(wo, &wo_end, &objects[i]);
-	}
-
-	/*
-	 * Then fill all the tagged tips.
-	 */
-	for (; i < nr_objects; i++) {
-		if (objects[i].tagged)
-			add_to_write_order(wo, &wo_end, &objects[i]);
-	}
-
-	/*
-	 * And then all remaining commits and tags.
-	 */
-	for (i = 0; i < nr_objects; i++) {
-		if (objects[i].type != OBJ_COMMIT &&
-		    objects[i].type != OBJ_TAG)
-			continue;
-		add_to_write_order(wo, &wo_end, &objects[i]);
-	}
+	wo_end = add_commits_to_write_order(wo);
 
 	/*
 	 * And then all the trees.

  parent reply	other threads:[~2011-07-08 22:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-08  0:24 [PATCH 0/2] For improved pack locality Junio C Hamano
2011-07-08  0:24 ` [PATCH 1/2] core: log offset pack data accesses happened Junio C Hamano
2011-07-08  0:24 ` [PATCH 2/2] pack-objects: optimize "recency order" Junio C Hamano
2011-07-08  2:08   ` Shawn Pearce
2011-07-08 17:45   ` Junio C Hamano
2011-07-11 22:49     ` Nicolas Pitre
2011-07-08 22:47   ` Junio C Hamano [this message]
2011-07-09  0:42     ` Shawn Pearce
2011-10-27 21:01   ` Ævar Arnfjörð Bjarmason
2011-10-27 21:49     ` Ævar Arnfjörð Bjarmason
2011-10-27 22:02       ` Ævar Arnfjörð Bjarmason
2011-10-27 22:32         ` Jakub Narebski
2011-10-27 22:05     ` Junio C Hamano
2011-10-28  9:17       ` Ævar Arnfjörð Bjarmason

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=7vfwmgfkzo.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    /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).