Re: [PATCH] read-tree --aggressive

From: Peter Eriksen <s022018@student.dtu.dk>
Date: Feb 4, 2006, 11:52 UTC
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:

Show 28 quoted lines

> "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

Show 7 quoted lines

> 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