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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Mon Oct 03 05:34:36 2005
This archive was generated by hypermail 2.1.8 : 2005-10-03 05:34:39 EST