Re: three-way diff performance problem

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 21, 2009, 20:34 UTC
Message-ID: <alpine.LFD.2.01.0907211324220.19335@localhost.localdomain>
In-Reply-To: <7vd47tes2y.fsf@alter.siamese.dyndns.org>

On Tue, 21 Jul 2009, Junio C Hamano wrote:

> 
> Here is a patch to do that.  I haven't tested it yet though.

Well, it seems to work.

It turned the 85+ minute thing (which I eventually just killed) into something that took 1.4 _seconds_. Of course, I didn't check that the end result was identical, since I never had the patience to wait for the original case.

Now sadly, my fixed test (which took 45 seconds before) didn't much improve (it doesn't have nearly as many removed lines, since I checked in the _right_ file that is a much closer version to the parent files).

But what is intriguing is that it it gets different results. So I suspect this one actually changed behavior some way:

	[torvalds@nehalem git-merge]$ time git show --color HEAD | wc
	  22671   63302  672234
	
	real	0m44.024s
	user	0m43.879s
	sys	0m0.148s

	[torvalds@nehalem git-merge]$ time ~/git/git show --color HEAD | wc
	  22596   63122  671076
	
	real	0m43.553s
	user	0m43.435s
	sys	0m0.128s

and notice how the git version with your change gives different line numbers.

Now, this is a diff, and different answers are possibly _both_ valid, so who knows. But I suspect that you _intended_ for the patch to be a semantic no-op, and it doesn't seem to be.

			Linus