On 8/10/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > 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. BTW, it maybe subjective, but diff-tree seem to have slowed down too. > > 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... No. I'd notice that. > > 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... Yep. One of the reasons to have source closed: so your customers do not see how dirty the mess they paid for is. - 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 Fri Aug 11 00:31:25 2006
This archive was generated by hypermail 2.1.8 : 2006-08-11 00:32:03 EST