Re: [ANNOUNCE] Stacked GIT 0.7

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Oct 2, 2005, 19:33 UTC
Message-ID: <b0943d9e0510021233n39daa5bao@mail.gmail.com>
In-Reply-To: <20051002121059.GA32367@elte.hu>

On 02/10/05, Ingo Molnar <mingo@elte.hu> wrote:

> i'm wondering - have you (or anyone else) done performance comparisons
> of quilt vs. stgit, using the same stack of patches? One of the most
> important features of quilt (for me) is that it's very fast at
> popping/pushing through hundreds of patches.

I've done some basic comparison and I must admit that Quilt is much faster than StGIT. Popping is done in O(1) and it is equivalent to a switch between two branches with 'git checkout' (can be less than 2 seconds with warm caches). Pushing without merging required (i.e. fast-forwarding) is the same as popping.

What's time consuming is pushing when the base of the stack was changed and merging is required. If the base changes do not involve file removals/additions, a push operations takes ~1.5s per patch with warm caches. Most of the time is spent in "git-read-tree -m" (StGIT doesn't consume resources since it mainly calls GIT tools). If the base changes involve file removals/additions, it can take considerably longer since for each file GIT needs to call an external merger. This could be solved by providing a smarter git-merge-index to deal with file removals/additions but the time won't be shorter than ~1.5s per patch.

An optimisation would be to keep the patches in diff format and apply them but this would mean losing the advantages of the three-way merging. Another issue is that git-apply doesn't support fuzzy patches, though I could emulate it using patch. But I'm not sure that's a good approach since I don't intend to re-write Quilt in Python. My hope is that git-read-tree will get faster :-).

-- Catalin