Re: git merge performance problem..

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Sat, 15 Jul 2006, Junio C Hamano wrote:
> 
> The code is to cull redundant parents primarily in octopus and
> is not strictly necessary.  Can I have the $head and $@ (the
> other merge parents, but in your case you never do an octopus so
> that would be the other branch head) to see what is going on
> please?

I think it was commit b20e481 that I reacted to this time, merging b5032a5 
and 48ce8b0.

Ie, lookie here:

	[torvalds@evo linux]$ time git merge-base --all b5032a5 48ce8b0
	672c6108a51bf559d19595d9f8193dfd81f0f752
	
	real    0m1.426s
	user    0m1.404s
	sys     0m0.016s

so it can find a merge-base in 1.4 seconds, which should certainly 
guarantee that they are independent. Then:

	[torvalds@evo linux]$ time git-show-branch --independent b5032a5 48ce8b0
	b5032a50aea76b6230db74b1d171a7f56b204bb7
	48ce8b056c88920c8ac187781048f5dae33c81b9
	
	real    0m30.657s
	user    0m30.414s
	sys     0m0.076s

Whee. Half a minute. Ok, so this is on my laptop (I'm oat the airport 
right now), so it was probably twice as fast on my desktop, but that is 
still not acceptable.

I really don't know what it's doing, because

	[torvalds@evo linux]$ time git-rev-list b5032a5 48ce8b0 > /dev/null 
	
	real    0m3.248s
	user    0m2.588s
	sys     0m0.036s

so it's really doing something very expensive - more so than just parsing 
the commits.

		Linus
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]