All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: [PATCH 11/11] Improve merge performance by avoiding in-index merges.
Date: Thu, 28 Dec 2006 02:35:34 -0500	[thread overview]
Message-ID: <20061228073534.GK17867@spearce.org> (raw)
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>

In the early days of Git we performed a 3-way read-tree based merge
before attempting any specific merge strategy, as our core merge
strategies of merge-one-file and merge-recursive were slower script
based programs which took far longer to execute.  This was a good
performance optimization in the past, as most merges were able to
be handled strictly by `read-tree -m -u`.

However now that merge-recursive is a C based program which performs
a full 3-way read-tree before it starts running we need to pay the
cost of the 3-way read-tree twice if we have to do any sort of file
level merging.  This slows down some classes of simple merges which
`read-tree -m -u` could not handle but which merge-recursive does
automatically.

For a really trivial merge which can be handled entirely by
`read-tree -m -u`, skipping the read-tree and just going directly
into merge-recursive saves on average 50 ms on my PowerPC G4 system.
May sound odd, but it does appear to be true.

In a really simple merge which needs to use merge-recursive to handle
a file that was modified on both branches, skipping the read-tree
in git-merge saves on average almost 100 ms (on the same PowerPC G4)
as we avoid doing some work twice.

We only avoid `read-tree -m -u` if the only strategy to use is
merge-recursive, as not all merge strategies perform as well as
merge-recursive does.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-merge.sh |   39 ++++++++++++++++++++++-----------------
 1 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/git-merge.sh b/git-merge.sh
index a8f673e..74d4fb0 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -341,23 +341,28 @@ f,*)
 ?,1,*,)
 	# We are not doing octopus, not fast forward, and have only
 	# one common.  See if it is really trivial.
-	git var GIT_COMMITTER_IDENT >/dev/null || exit
-
-	echo "Trying really trivial in-index merge..."
-	git-update-index --refresh 2>/dev/null
-	if git-read-tree --trivial -m -u -v $common $head "$1" &&
-	   result_tree=$(git-write-tree)
-	then
-	    echo "Wonderful."
-	    result_commit=$(
-	        echo "$merge_msg" |
-	        git-commit-tree $result_tree -p HEAD -p "$1"
-	    ) || exit
-	    finish "$result_commit" "In-index merge"
-	    dropsave
-	    exit 0
-	fi
-	echo "Nope."
+	case "$use_strategies" in
+	recursive|'recursive '|recur|'recur ')
+		: run merge later
+		;;
+	*)
+		git var GIT_COMMITTER_IDENT >/dev/null || exit
+		echo "Trying really trivial in-index merge..."
+		git-update-index --refresh 2>/dev/null
+		if git-read-tree --trivial -m -u -v $common $head "$1" &&
+		   result_tree=$(git-write-tree)
+		then
+			echo "Wonderful."
+			result_commit=$(
+				echo "$merge_msg" |
+				git-commit-tree $result_tree -p HEAD -p "$1"
+			) || exit
+			finish "$result_commit" "In-index merge"
+			dropsave
+			exit 0
+		fi
+		echo "Nope."
+	esac
 	;;
 *)
 	# An octopus.  If we can reach all the remote we are up to date.
-- 
1.4.4.3.gd2e4

  parent reply	other threads:[~2006-12-28  7:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
2006-12-28  7:34 ` [PATCH 2/11] Honor GIT_REFLOG_ACTION in git-rebase Shawn O. Pearce
2006-12-28  7:34 ` [PATCH 3/11] Use branch names in 'git-rebase -m' conflict hunks Shawn O. Pearce
2006-12-28  7:35 ` [PATCH 4/11] Ensure `git-pull` fails if `git-merge` fails Shawn O. Pearce
2006-12-28  7:35 ` [PATCH 5/11] Honor pull.{twohead,octopus} in git-merge Shawn O. Pearce
2006-12-28  7:35 ` [PATCH 6/11] Allow git-merge to select the default strategy Shawn O. Pearce
2006-12-28  7:35 ` [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible Shawn O. Pearce
2006-12-28  8:08   ` Junio C Hamano
2006-12-28  8:17     ` Shawn Pearce
2006-12-28  9:35       ` Junio C Hamano
2006-12-28  7:35 ` [PATCH 8/11] Move better_branch_name above get_ref in merge-recursive Shawn O. Pearce
2006-12-28  7:35 ` [PATCH 9/11] Allow merging bare trees " Shawn O. Pearce
2006-12-28  8:08   ` Junio C Hamano
2006-12-28  7:35 ` [PATCH 10/11] Use merge-recursive in git-am -3 Shawn O. Pearce
2006-12-28  7:35 ` Shawn O. Pearce [this message]
2006-12-28  8:08   ` [PATCH 11/11] Improve merge performance by avoiding in-index merges Junio C Hamano
2006-12-28  8:24     ` Shawn Pearce
2006-12-29 17:44       ` Johannes Schindelin

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=20061228073534.GK17867@spearce.org \
    --to=spearce@spearce.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.