Hi, On Thu, 10 Aug 2006, Alex Riesen wrote: > On 8/10/06, Junio C Hamano <junkio@xxxxxxx> wrote: > > - A new merge strategy, merge-recur, which is a rewrite of > > merge-recursive in C, by Johannes and Alex. > > It still has problems devouring that monster merge I have (~20k entries, > with around 40 changed in the other branch, around 100 revs ago. Big > binary files involved. Renames and copies). > Perfomance is nowhere near usable: ~20min on Windows/3GHz/2Gb, > ~4Min on Linux/1.4GHz/384Mb ;) I agree that Linux is much more bearable > but 4Min is still too much (especially comparing to that "stupid" resolve). > > I noticed that it spends a lot of time finding renames (diffcore_std, > in particular). My next plans -- after making sure that merge-recursive is accurate (enough) -- was to use oprofile to find the expensive spots. > Why doesn't it take that much time for "diff-tree -M -r base head1" + > "diff-tree -M -r base head2", I wonder...? (~30 sek, for that windows box). Could it be that it has many common ancestors? You have to do the rename handling twice for each merge... > Sorry, I can't provide the tree. I suppose Mozilla tree can be compared > to that thing, when it becomes available. Linux kernel is no good for > reproducing this problem: it's too clean and compact. The beauty of Open Source: since everyone can see your mess, you tend to be tidier... Ciao, Dscho - : 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