Paul Burba wrote:
> Stefan Fuhrmann wrote:
> > Paul Burba wrote:
> >> Stefan Fuhrmann wrote:
> > Here we go (SVN 1.6.0-RC3, i686 LINUX):
> >
> > $time ./svn co http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk ~/TSVN
> > -r 15533 --ignore-externals > /dev/null
> >
> > serf neon
> > real 2m41.073s 2m15.268s
> > user 0m54.107s 0m6.840s
> > sys 1m25.297s 0m3.672s
> >
> > $time ./svn merge -r 15456:15455
> > http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk ~/TSVN
> >
> > serf neon
> > real 5m29.002s 6m43.831s
> > user 0m1.992s 0m2.124s
> > sys 0m0.824s 0m0.664s
> >
> > Hm. Merge is 20% faster over Serf but c/o is 20% slower.
> > More importantly, c/o is CPU-bound with Serf!
> > That is really unexpected.
>
> Hmmmm, that is unexpected.
Perhaps I can come up with some profiling data over the weekend.
> >> Beyond that, improvements are going to be harder to come by in this
> >> example because http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk
> >> has so much explicit subtree mergeinfo, *226* paths in fact! I assume
> >> this is what you are referring to as "every 'relevant' node". Do you
> >> know how all of this mergeinfo came about? Do you do 'subtree
> >> merges'? (i.e. a merge directly targeting a subtree of a branch rather
> >> than its root).
> >
> > [snip: caused by 1.5-alpha against 1.3 server]
> >
> > From what I can tell, most of that merge info can
> > be deleted because they refer to revision that did
> > not change the source node. Is it safe to do that or
> > will I screw up the current merge tracking logic?
>
> It really depends on what the subtree mergeinfo is overriding (i.e.
> what would the path inherit for mergeinfo if it had no mergeinfo of
> its own). Most of subtree mergeinfo on
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk is coming from the
> '/branches/1.4.x/' and '/branches/LogCacheEnhancement' branches.
> Assuming you won't be merging from those branches to trunk (directly
> or from copies of those branches) then I am quite confident you can
> safely delete the mergeinfo from those subtrees.
Those branches were closed long time ago.
It seems that also simple renames / moves
created mergeinfo as well back then.
I removed the obsolete mergeinfo and performance
is as good as one can expect (reverse-merge r15570):
1.6.0RC3-serf: real ~11sec, CPU ~1.1sec
1.6.0RC3-neon: real ~15sec, CPU ~1.1sec
(same timings for --ignore-ancestry)
trunk_at_36489-serf: real ~11sec, CPU ~1.1sec
trunk_at_36489-neon: real ~10sec, CPU ~1.1sec
with --ignore-ancestry
trunk_at_36489-serf: real ~8sec, CPU ~0.1sec
trunk_at_36489-neon: real ~9sec, CPU ~0.1sec
You did a very good job with the latest trunk patches!
Neon and serf seem now to be on par performance-wise.
The remaining run-time can be attributed to svn diff.
Perhaps we can shave off some of that, too?
> >> Anyhow, I'll be looking at the code again to see where improvements can
> >> be made.
> >
> > Thanks!
>
> In r36444 I made a minor tweak to the merge code that potentially
> avoids a network round trip for some or all of the subtrees with
> explicit mergeinfo in the merge target. In your original example this
> optimization is in full effect and now the merge takes just over two
> minutes for me (using serf):
>
> C:\SVN\TSVN.trunk>timethis svn merge -r 15456:15455
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk
>
> TimeThis : Command Line : svn merge -r 15456:15455
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk
> TimeThis : Start Time : Mon Mar 09 13:59:07 2009
>
> --- Reverse-merging r15456 into
> 'src\TortoiseProc\RevisionGraph\RevisionGraphDlg.cpp':
> U src\TortoiseProc\RevisionGraph\RevisionGraphDlg.cpp
> --- Reverse-merging r15456 into
> 'src\TortoiseProc\RevisionGraph\RevisionGraphDlg.h':
> U src\TortoiseProc\RevisionGraph\RevisionGraphDlg.h
>
> TimeThis : Command Line : svn merge -r 15456:15455
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk
> TimeThis : Start Time : Mon Mar 09 13:59:07 2009
> TimeThis : End Time : Mon Mar 09 14:01:18 2009
> TimeThis : Elapsed Time : 00:02:11.296
>
> This is still slow, but is big improvement. I'm looking into further
> improvements so hopefully there is more to come.
Numbers over my DSL line:
trunk_at_36489-serf: real ~193sec, CPU ~2.6sec
trunk_at_36489-neon: real ~193sec, CPU ~2.6sec
with --ignore-ancestry
trunk_at_36489-serf: real ~11sec, CPU ~0.1sec
trunk_at_36489-neon: real ~9sec, CPU ~0.1sec
So, neon and serf on par again, --ignore-ancestry about
as fast as with no mergeinfo properties. Last but not least
a very impressive 100% performance boost.
Maybe, there should be a FAQ entry about avoiding merges
in sub-trees.
-- Stefan^2.
Received on 2009-03-11 22:12:05 CET