Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.

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

 



Junio C Hamano <junkio@xxxxxxx> wrote:
> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> 
> > 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.
> 
> This sounds awfully attractive yet disruptive.  Should be cooked
> in 'next' for at least two weeks, maybe even longer to verify
> that performance figure holds for everybody.

I agree.  I have been thinking about doing this for a while but
just never sat down and did it until night.  To get it in 1.5.0 I
probably should have done this back in early Decmember.  Whoops,
bad timing on my part.  ;-)
 
> Also I think you need to make sure running merge-recursive
> upfront offers the same safety as the code you are removing then
> running it, as I vaguely recall its checking for local changes
> were slightly looser.

>From what I can tell, merge-recursive and read-tree -m are running
exactly the same code.  So aside from the fact that I bypassed the
update-index --refresh by accident, I don't think they will have
different outcomes.

-- 
Shawn.
-
To unsubscribe from this list: 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]