Fix "git commit directory/" performance anomaly

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Junio C Hamano <gitster@...>
Cc: Sean <seanlkml@...>, moe <moe-git@...>, <git@...>
Date: Friday, August 10, 2007 - 12:51 pm

This trivial patch avoids re-hashing files that are already clean in the 
index. This mirrors what commit 0781b8a9b2fe760fc4ed519a3a26e4b9bd6ccffe 
did for "git add .", only for "git commit ." instead.

This improves the cold-cache case immensely, since we don't need to bring 
in all the file contents, just the index and any files dirty in the index.

Before:

	[torvalds@woody linux]$ time git commit .
	real    1m49.537s
	user    0m3.892s
	sys     0m2.432s

After:

	[torvalds@woody linux]$ time git commit .
	real    0m14.273s
	user    0m1.312s
	sys     0m0.516s

(both after doing a "echo 3 > /proc/sys/vm/drop_caches" to get cold-cache 
behaviour - even with the index optimization git still has to "lstat()" 
all the files, so with a truly cold cache, bringing all the inodes in 
will take some time).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---

On Fri, 10 Aug 2007, Linus Torvalds wrote:
---
 builtin-update-index.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/builtin-update-index.c b/builtin-update-index.c
index 509369e..8d22dfa 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -86,9 +86,15 @@ static int process_lstat_error(const char *path, int err)
 
 static int add_one_path(struct cache_entry *old, const char *path, int len, struct stat *st)
 {
-	int option, size = cache_entry_size(len);
-	struct cache_entry *ce = xcalloc(1, size);
+	int option, size;
+	struct cache_entry *ce;
+
+	/* Was the old index entry already up-to-date? */
+	if (old && !ce_stage(old) && !ce_match_stat(old, st, 0))
+		return;
 
+	size = cache_entry_size(len);
+	ce = xcalloc(1, size);
 	memcpy(ce->name, path, len);
 	ce->ce_flags = htons(len);
 	fill_stat_cache_info(ce, st);
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
git and larger trees, not so fast?, moe, (Thu Aug 9, 12:30 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Sat Aug 11, 2:47 pm)
Re: git and larger trees, not so fast?, moe, (Sat Aug 11, 4:06 pm)
Re: git and larger trees, not so fast?, moe, (Wed Aug 22, 8:30 pm)
Re: git and larger trees, not so fast?, Fernando J. Pereda, (Sat Aug 11, 3:02 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Sat Aug 11, 4:38 pm)
Re: git and larger trees, not so fast?, Fernando J. Pereda, (Sat Aug 11, 4:51 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Sat Aug 11, 6:27 pm)
Re: git and larger trees, not so fast?, David Kastrup, (Sat Aug 11, 7:26 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Fri Aug 10, 3:39 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Thu Aug 9, 1:11 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Thu Aug 9, 1:54 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Thu Aug 9, 1:38 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Thu Aug 9, 2:06 pm)
Re: git and larger trees, not so fast?, Junio C Hamano, (Thu Aug 9, 2:11 pm)
Re: git and larger trees, not so fast?, Junio C Hamano, (Thu Aug 9, 4:42 pm)
Re: git and larger trees, not so fast?, Sean, (Thu Aug 9, 4:52 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Thu Aug 9, 5:41 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Thu Aug 9, 5:46 pm)
Re: git and larger trees, not so fast?, Junio C Hamano, (Thu Aug 9, 6:02 pm)
Re: git and larger trees, not so fast?, Daniel Barkalow, (Thu Aug 9, 9:42 pm)
Re: git and larger trees, not so fast?, Junio C Hamano, (Thu Aug 9, 7:38 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Thu Aug 9, 8:44 pm)
Re: git and larger trees, not so fast?, Junio C Hamano, (Thu Aug 9, 8:51 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Thu Aug 9, 8:57 pm)
Re: git and larger trees, not so fast?, Junio C Hamano, (Thu Aug 9, 11:48 pm)
Re: git and larger trees, not so fast?, Linus Torvalds, (Fri Aug 10, 12:07 pm)
Fix "git commit directory/" performance anomaly, Linus Torvalds, (Fri Aug 10, 12:51 pm)
Re: Fix "git commit directory/" performance anomaly, Junio C Hamano, (Fri Aug 10, 2:31 pm)
Re: Fix "git commit directory/" performance anomaly, Linus Torvalds, (Fri Aug 10, 2:56 pm)
Re: Fix "git commit directory/" performance anomaly, Linus Torvalds, (Fri Aug 10, 1:14 pm)
Re: git and larger trees, not so fast?, Junio C Hamano, (Fri Aug 10, 1:55 am)
Re: git and larger trees, not so fast?, Linus Torvalds, (Fri Aug 10, 11:49 am)
Re: git and larger trees, not so fast?, Junio C Hamano, (Thu Aug 9, 8:04 pm)
Re: git and larger trees, not so fast?, Junio C Hamano, (Thu Aug 9, 5:37 pm)
Re: git and larger trees, not so fast?, Junio C Hamano, (Thu Aug 9, 2:00 pm)