Use less memory in "git log"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This trivially avoids keeping the commit message data around after we 
don't need it any more, avoiding a continually growing "git log" memory 
footprint.

It's not a huge deal, but it's somewhat noticeable. For the current kernel 
tree, doing a full "git log" I got

 - before: /usr/bin/time git log > /dev/null 
	0.81user 0.02system 0:00.84elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
	0inputs+0outputs (0major+8851minor)pagefaults 0swaps

 - after: /usr/bin/time git log > /dev/null 
	0.79user 0.03system 0:00.83elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
	0inputs+0outputs (0major+5039minor)pagefaults 0swaps

ie the touched pages dropped from 8851 to 5039. For the historic kernel 
archive, the numbers are 18357->11037 minor page faults.

We could/should in theory free the commits themselves, but that's really a 
lot harder, since during revision traversal we may hit the same commit 
twice through different children having it as a parent, even after we've 
shown it once (when that happens, we'll silently ignore it next time, but 
we still need the "struct commit" to know).

And as the commit message data is clearly the biggest part of the commit, 
this is the really easy 60% solution.

Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
---
diff --git a/git.c b/git.c
index d6f17db..78ed403 100644
--- a/git.c
+++ b/git.c
@@ -391,6 +391,8 @@ static int cmd_log(int argc, const char 
 		if (do_diff)
 			log_tree_commit(&opt, commit);
 		shown = 1;
+		free(commit->buffer);
+		commit->buffer = NULL;
 	}
 	free(buf);
 	return 0;
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]