* Sergey Vlasov <vsu@xxxxxxxxxxx> wrote: > On Wed, 23 Jul 2008 15:05:18 +0200 Ingo Molnar wrote: > > > Anyone can simulate it by switching to the linus/master branch of the > > current Linux kernel tree, and doing: > > > > time for ((i=0; i<140; i++)); do git-merge v2.6.26; done > > > > real 1m26.397s > > user 1m10.048s > > sys 0m13.944s > > Timing results here (E6750 @ 2.66GHz): > 41.61s user 3.71s system 99% cpu 45.530 total > > However, testing whether there is something new to merge could be > performed significantly faster: > > $ time sh -c 'for ((i=0; i<140; i++)); do [ -n "$(git rev-list --max-count=1 v2.6.26 ^HEAD)" ]; done' > sh -c 5.49s user 0.26s system 99% cpu 5.786 total > > The same loop with "git merge-base v2.6.26 HEAD" takes about 40 > seconds here - apparently finding the merge base is the expensive > part, and it makes sense to avoid it if you expect that most of your > branches do not contain anything new to merge. using git-fastmerge i get 2.4 seconds: $ time for ((i=0; i<140; i++)); do git-fastmerge v2.6.26; done [...] real 0m2.388s user 0m1.211s sys 0m1.131s for something that 'progresses' in a forward manner (which merges do fundamentally) nothing beats the performance of a timestamped cache i think. at least for my usecase. Even assuming that the filesystem is sane, is my merge-cache implementation semantically equivalent to a git-merge? One detail is that i suspect it is not equivalent in the git-merge --no-ff case. (but that is a not too interesting non-default case anyway) Ingo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
