Re: [ANNOUNCE] Stacked GIT 0.7

On 02/10/05, Ingo Molnar [off-list ref] 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