git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/1] Bypass expensive content comparsion during rename detection.

From
Shawn Pearce <spearce@spearce.org>
Date
Dec 14, 2006, 11:50 UTC
Message-ID
<20061214115054.GJ1747@spearce.org>
In-Reply-To
<Pine.LNX.4.63.0612141214440.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 19 quoted lines
> Hi,
> 
> On Thu, 14 Dec 2006, Shawn Pearce wrote:
> 
> > My first version of the patch had the hash comparsion right after we 
> > called diff_populate_filespec to get the size data.  But then I realized 
> > that very often the sizes will be different and the src->size != 
> > dst->size comparsion will tend to be true most of the time, thus saving 
> > us a (relatively) expensive hash comparsion, which we know must fail 
> > anyway if the sizes differed.
> 
> Ah! I misunderstood. Since the call to diff_populate_filespec was not 
> visible in the hunk, I erroneously assumed that you meant to _check_ the 
> sizes before checking the hashes.
> 
> But your explanation makes lots of sense to me. May I request a short 
> comment above the new code, like "let diff_populate_filespec() do its 
> thing since we need the filesize later on anyway, and having that, do the 
> cheaper filesize check before the more expensive hashcmp()"?

-- 8> -- Bypass expensive content comparsion during rename detection.

When comparing file contents during the second loop through a rename detection attempt we can skip the expensive byte-by-byte comparsion if both source and destination files have valid SHA1 values. This improves performance by avoiding either an expensive open/mmap to read the working tree copy, or an expensive inflate of a blob object.

Unfortunately we still have to at least initialize the sizes of the source and destination files even if the SHA1 values don't match. Failing to initialize the sizes causes a number of test cases to fail and start reporting different copy/rename behavior than was expected.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 diffcore-rename.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 57a74b6..f7748ce 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -109,6 +109,15 @@ static int is_exact_match(struct diff_filespec *src,
 		return 0;
 	if (src->size != dst->size)
 		return 0;
+	/* Although we can avoid a byte-by-byte comparsion by checking
+	 * hashes we needed to allow diff_populate_filespec to fill in
+	 * the size members, as we need that later on to correctly do
+	 * rename and copy detection.  Not filling in size before we
+	 * return back when contents_too is true causes all sorts of
+	 * havoc (been there, done that, lets not try it again).
+	 */
+	if (src->sha1_valid && dst->sha1_valid)
+	    return !hashcmp(src->sha1, dst->sha1);
 	if (diff_populate_filespec(src, 0) || diff_populate_filespec(dst, 0))
 		return 0;
 	if (src->size == dst->size &&
-- 
1.4.4.2.g72f5
Previous: Johannes Schindelin
Message 6 of 6 in “Bypass expensive content comparsion during rename detection.”
  1. 1/1 Bypass expensive content comparsion during rename detection.Shawn O. Pearce, Dec 14, 2006
  2. Johannes SchindelinDec 14, 2006
  3. Shawn PearceDec 14, 2006
  4. Shawn PearceDec 14, 2006
  5. Johannes SchindelinDec 14, 2006
  6. Shawn PearceDec 14, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.