Avoid building object ref lists when not needed

Subsystems: the rest

2 messages, 1 author, 2016-06-15 · open the first message on its own page

Avoid building object ref lists when not needed

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:06

The object parsing code builds a generic "this object references that 
object" because doing a full connectivity check for fsck requires it.

However, nothing else really needs it, and it's quite expensive for 
git-rev-list that can have tons of objects in flight.

So, exactly like the commit buffer save thing, add a global flag to 
disable it, and use it in git-rev-list.

Before:

	[torvalds@g5 linux]$ /usr/bin/time git-rev-list --objects v2.6.12..HEAD | wc -l
	12.28user 0.29system 0:12.57elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
	0inputs+0outputs (0major+26718minor)pagefaults 0swaps
	59124

After this change:

	[torvalds@g5 linux]$ /usr/bin/time git-rev-list --objects v2.6.12..HEAD | wc -l
	10.33user 0.18system 0:10.54elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
	0inputs+0outputs (0major+18509minor)pagefaults 0swaps
	59124

and note how the number of pages touched by git-rev-list for this
particular object list has shrunk from 26,718 (104 MB) to 18,509 (72 MB).

Calculating the total object difference between two git revisions is still
clearly the most expensive git operation (both in memory and CPU time),
but it's now less than 40% of what it used to be.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
diff --git a/object.c b/object.c
--- a/object.c
+++ b/object.c
@@ -9,6 +9,8 @@ struct object **objs;
 int nr_objs;
 static int obj_allocs;
 
+int track_object_refs = 1;
+
 static int find_object(const unsigned char *sha1)
 {
 	int first = 0, last = nr_objs;
@@ -67,9 +69,12 @@ void created_object(const unsigned char 
 
 void add_ref(struct object *refer, struct object *target)
 {
-	struct object_list **pp = &refer->refs;
-	struct object_list *p;
-	
+	struct object_list **pp, *p;
+
+	if (!track_object_refs)
+		return;
+
+	pp = &refer->refs;
 	while ((p = *pp) != NULL) {
 		if (p->item == target)
 			return;
@@ -87,6 +92,8 @@ void mark_reachable(struct object *obj, 
 {
 	struct object_list *p = obj->refs;
 
+	if (!track_object_refs)
+		die("cannot do reachability with object refs turned off");
 	/* If we've been here already, don't bother */
 	if (obj->flags & mask)
 		return;
diff --git a/object.h b/object.h
--- a/object.h
+++ b/object.h
@@ -17,6 +17,7 @@ struct object {
 	void *util;
 };
 
+extern int track_object_refs;
 extern int nr_objs;
 extern struct object **objs;
 
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -581,6 +581,7 @@ int main(int argc, char **argv)
 	}
 
 	save_commit_buffer = verbose_header;
+	track_object_refs = 0;
 
 	if (!merge_order) {		
 		sort_by_date(&list);

Re: Avoid building object ref lists when not needed

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:06


On Fri, 16 Sep 2005, Linus Torvalds wrote:
and note how the number of pages touched by git-rev-list for this
particular object list has shrunk from 26,718 (104 MB) to 18,509 (72 MB).
One final note: since I'm only looking at the total page footprint for the 
process, this _includes_ all the mmap faults of not just the executable, 
but since my kernel is usign a packed archive, also the actual mapping of 
the pack itself.

The pack itself is 76MB in size, but obviously not all of it actually
needs to be read in. For example, it doesn't need to actually read any of
the objects themselves (that's done by the actual packing phase), so we're
only touching the "commit" and "tree" parts of the pack.

Of the 72MB, valgrind reports that "only" about 24MB is now used for
actual malloc'ed memory. So while the _total_ "touched pages" have shrunk
from 187 MB (when I started) to 72 MB (now), the malloc()'ed memory has
actually shrunk a lot more (all the savings have been by either avoiding 
allocations altogether, or by freeing them as soon as we can).

I'm done for the while. There are small wins still to be had, but they are 
smaller and harder to reach. Maybe I'll get a spurt of energy one of these 
days, so if somebody finds a particularly problematic load, tell me.

		Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help