Paul Burba <ptburba_at_gmail.com> wrote:
> This delay was due to a needless walk of the merge target looking for
> subtrees with mergeinfo. If we stop this walk then the
> --ignore-ancestry merge with 1.6.0.RC3 is more on par with 1.4.6:
>
> 1.6.0.RC3.PATCHED>C:\SVN\TSVN>timethis svn merge -r 15456:15455
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk --ignore-ancestry
>
> TimeThis : Command Line : svn merge -r 15456:15455
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk --ignore-ancestry
> TimeThis : Start Time : Mon Mar 02 14:16:54 2009
>
> --- Reverse-merging r15456 into '.':
> U src\TortoiseProc\RevisionGraph\RevisionGraphDlg.cpp
> U src\TortoiseProc\RevisionGraph\RevisionGraphDlg.h
>
> TimeThis : Command Line : svn merge -r 15456:15455
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk --ignore-ancestry
> TimeThis : Start Time : Mon Mar 02 14:16:54 2009
> TimeThis : End Time : Mon Mar 02 14:17:10 2009
> TimeThis : Elapsed Time : 00:00:16.093
>
> I'll commit this improvement to trunk and nominate it for backport to
> 1.5.x and 1.6.x. Obviously this does not address the merge aware
> performance that caused Stefan to start this thread,
Very good! At least there is a workaround for the issue
initially reported.
I did some more tests and found that the runtime for
'ordinary' merges between branches is roughly the same
(4+ minutes instead of 6+ but the sub-tree in question was
significantly smaller on that branch).
> but it does tell
> us something we already knew: A significant part of merge's slowdown
> in 1.5.0+ is due to the need to walk the working copy looking for
> explicit subtree mergeinfo. This is not something we can skip for
> mergeinfo aware merges, we need to know about these subtrees. Though
> the ongoing WCNG work will probably make it a *lot* faster.
Hm. Looking at the measured data tells a different story:
the client is responsible for less than 1% of the runtime
(<3s of 350s total). The very constant flow of data between
client and server is an indication for a similar situation on
the server.
That means, the most time is spent on the network with
1500 .. 2000 roundtrips (given a 187ms ping). So, you are
right that the whole WC is crawled for mergeinfo. But the
real problem is that for every 'relevant' node, there is an
individual communication with the server. A faster WC
implementation alone will have no effect here.
IMHO, there are two approaches to speeding things up:
* stream / interleave C/S communication
(would serf be of any help here?)
* aggregate communication into larger digests
(e.g. one per folder)
Given the assumed high number of roundtrips, you may
spend a lot more CPU cycles on the client if that helps
to reduce network time.
> There
> might also be some special casing we can do for reverse merges from a
> path's own natural history, I'll look into that.
That would certainly help because TSVN users may not
realize that 'revert changes from this revision' is actually
a merge.
-- Stefan^2.
Received on 2009-03-04 11:27:31 CET