From: Karl Hasselström Date: Mon, 14 Jul 2008 06:32:56 GMT Subject: Re: [StGit PATCH 03/14] Write to a stack log when stack is modified Message-ID: <20080714063256.GC20751@diana.vm.bytemark.co.uk> In-Reply-To: On 2008-07-12 11:09:18 +0100, Catalin Marinas wrote: > 2008/6/23 Karl Hasselström : > > > 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@treskal.com www.treskal.com/kalle