From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <junkio@cox.net>, Git Mailing List <git@vger.kernel.org>
Subject: [PATCH 3/2] Optimize the two-way merge of git-read-tree too
Date: Fri, 10 Aug 2007 12:31:20 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.0.999.0708101224110.30176@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0708101216000.30176@woody.linux-foundation.org>
This trivially optimizes the two-way merge case of git-read-tree too,
which affects switching branches.
When you have tons and tons of files in your repository, but there are
only small differences in the branches (maybe just a couple of files
changed), the biggest cost of the branch switching was actually just the
index calculations.
This fixes it (timings for switching between the "testing" and "master"
branches in the 100,000 file testing-repo-from-hell, where the branches
only differ in one small file).
Before:
[torvalds@woody bummer]$ time git checkout master
real 0m9.919s
user 0m8.461s
sys 0m0.264s
After:
[torvalds@woody bummer]$ time git checkout testing
real 0m0.576s
user 0m0.348s
sys 0m0.228s
so it's easily an order of magnitude different.
This concludes the series. I think we could/should do the three-way merge
too (to speed up merges), but I'm lazy. Somebody else can do it.
The rule is very simple: you need to remove the old entry if:
- you want to remove the file entirely
- you replace it with a "merge conflict" entry (ie a non-stage-0 entry)
and you can avoid removing it if you either
- keep the old one
- or resolve it to a new one.
and these rules should all be valid for the three-way case too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
commit b8d8d6aa12a3ae7e2f7a8cb008413b780e1152ce
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri Aug 10 12:13:41 2007 -0700
Optimize the common cases of git-read-tree
This optimizes bind_merge() and oneway_merge() to not unnecessarily
remove and re-add the old index entries when they can just get replaced
by updated ones.
This makes these operations much faster for large trees (where "large"
is in the 50,000+ file range), because we don't unnecessarily move index
entries around in the index array all the time.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
unpack-trees.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index b4e2618..810816e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -827,7 +827,6 @@ int twoway_merge(struct cache_entry **src,
struct cache_entry *oldtree = src[1];
struct cache_entry *newtree = src[2];
- remove_entry(remove);
if (o->merge_size != 2)
return error("Cannot do a twoway merge of %d trees",
o->merge_size);
@@ -850,6 +849,7 @@ int twoway_merge(struct cache_entry **src,
}
else if (oldtree && !newtree && same(current, oldtree)) {
/* 10 or 11 */
+ remove_entry(remove);
return deleted_entry(oldtree, current, o);
}
else if (oldtree && newtree &&
@@ -859,6 +859,7 @@ int twoway_merge(struct cache_entry **src,
}
else {
/* all other failures */
+ remove_entry(remove);
if (oldtree)
reject_merge(oldtree);
if (current)
@@ -870,8 +871,8 @@ int twoway_merge(struct cache_entry **src,
}
else if (newtree)
return merged_entry(newtree, current, o);
- else
- return deleted_entry(oldtree, current, o);
+ remove_entry(remove);
+ return deleted_entry(oldtree, current, o);
}
/*
next prev parent reply other threads:[~2007-08-10 19:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LFD.0.999.0708101213560.30176@woody.linux-foundation.or g>
2007-08-10 19:15 ` [PATCH 1/2] Move old index entry removal from "unpack_trees()" into the individual functions Linus Torvalds
2007-08-10 19:21 ` [PATCH 2/2] Optimize the common cases of git-read-tree Linus Torvalds
2007-08-10 19:31 ` Linus Torvalds [this message]
2007-08-10 19:53 ` [PATCH 3/2] Optimize the two-way merge of git-read-tree too Linus Torvalds
2007-08-11 5:57 ` Junio C Hamano
2007-08-11 9:17 ` Junio C Hamano
2007-08-11 17:27 ` Linus Torvalds
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.0.999.0708101224110.30176@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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.
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 NNTP newsgroup(s).