From: Catalin Marinas Date: Sun, 02 Oct 2005 19:33:54 GMT Subject: Re: [ANNOUNCE] Stacked GIT 0.7 Message-ID: In-Reply-To: <20051002121059.GA32367@elte.hu> On 02/10/05, Ingo Molnar 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