From: Peter Eriksen <s022018@student.dtu.dk>
Date: Sat, 04 Feb 2006 11:52:01 GMT
Subject: Re: [PATCH] read-tree --aggressive
Message-ID: <20060204115201.GA22333@ebar091.ebar.dtu.dk>
In-Reply-To: <7v8xsr60n2.fsf@assigned-by-dhcp.cox.net>

On Fri, Feb 03, 2006 at 11:31:13PM -0800, Junio C Hamano wrote:
> "Peter Eriksen" <s022018@student.dtu.dk> writes:
> 
> > In connection with Ian Molton's question about merge have I played a
> > little with 'git merge' on the kernel sources.  What I find is that a
> > merge can take quite some time, but I'm not sure where that time exactly
> > goes to.  Here are the times I got:
> >
> > Recursive (default):  4m22.282s
> > Resolve (-s resolve): 3m23.548s
> 
> In your sample script, you do not disable the post-merge diff,
> which is typically one of the most expensive part in the whole
> merge, and I am wondering how fast a machine you are using to
> get 4 minutes.  The post-merge diff is generated by piping the
> output of 'diff-tree -M' to 'apply --stat --summary', and that
> step alone takes about 12 minutes wallclock time on my box X-<.
> 
> Since my box is not as fast as yours, I've eliminated the
> post-merge diff step and tried your final merge step like this:
> 
> 	$ time git merge --no-summary -s resolve \
>             'Merging happily' HEAD v2.6.15 >/dev/null
> 
> and got this:
> 
>         real	2m15.737s
>         user	1m43.320s
>         sys	0m26.690s

I got this:

real    0m51.661s
user    0m28.302s
sys     0m8.949s

> With the attached patch, the most expensive part, which is the
> repeated invocation of git-merge-one-file to remove many deleted
> paths, is eliminated.  The result is this.
> 
>         real	0m20.311s
>         user	0m15.780s
>         sys	0m4.150s

I got this:

real    0m20.221s
user    0m6.456s
sys     0m1.828s

> This patch would not help recursive strategy, though.  Calling
> read-tree with --aggressive flag essentially disables the
> benefit we would expect to get from it -- rename detection.

Aha, so now I better understand where all the time goes.  Most of the
time is spend calculating the merge summary.  After that the bottleneck
was the large amount of git-merge-one-file invocations.

With the aggressive patch applied it feels like the merge is mostly IO
bound, which might explain why we get similar running times.  I did get
one run of 12s, but that was a lucky shot I guess.  Repeated runs gave
between 15s and 21s but most where close to 20s.

Thanks,

Peter