On 2008-07-12 11:09:18 +0100, Catalin Marinas wrote:
> 2008/6/23 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > Two optimizations would hopefully make it fast:
> >
> > 1. If the patch's sha1 hasn't changed, we don't have to
> > regenerate the diff.
> >
> > 2. If the patch's sha1 has changed, but git apply was sufficient
> > during the merge stage, we can just reuse that patch. We do
> > have to write it to a blob, but we have already generated the
> > diff and don't need to do so again. (I've shamelessly stolen
> > your idea here.)
>
> It can be optimised a bit more to actually apply the diff in the
> blob directly rather than the current way of generating the diff
> (since we don't store the diff).
Ah. Yes, that might be faster. While git is supposedly very fast in
diffing two trees, it should be even faster in just reading a blob.
> > In most cases, (1) would make sure that only a small handful of
> > patches would need to be considered. In the cases where a lot of
> > patches are touched, such as rebase, (2) would provide a good
> > speedup (except for the cases where we had to call
> > merge-recursive, and those are slow anyway).
>
> I think it should work. Rebase is indeed my worry but it might be
> even faster for most of the patches to apply the blob than computing
> the diff. In my experience with the Linux kernel, full merge is
> rarely needed.
Yes. Now all we need is a good benchmarking system so that we know
we're heading in the right direction. I need to fix up and post that
script I used.
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
--
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
