Re: [ANNOUNCE] Stacked GIT 0.7

[Catalin Marinas <catalin.marinas@gmail.com>]

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