Mark Phippard wrote:
> On Wed, Mar 4, 2009 at 5:29 AM, Stefan Fuhrmann
>
> <stefanfuhrmann_at_alice-dsl.de> wrote:
> > 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.
>
> I wonder if this is now where you are running into the optimization
> that went into 1.5. Before you did the merge, did you run update so
> that your WC was at a single revision for the entire WC? This has an
> enormous impact on performance and I think this is what you were
> running into. Paul can describe it better, but if the WC is not at a
> single revision then the code has to do more roundtrips to discover
> mergeinfo that might exist in the repository.
Those WCs were fresh check-outs. Paul, I guess, also just
made a check out and started his timings.
The svn:externals used by TSVN don't seem to be the culprit
either, because the timing was only proportionally better
when I used a smaller sub-tree with no externals in it.
Back to your question whether this is a release blocker: No.
Performance got much worse in 1.5 but remained stable in 1.6.
So 1.6 performance is just as acceptable as the previous version.
I provided the reproduction recipe with some public, real-world
repo so that Paul and others could analyze it thoroughly and
make it faster.
-- Stefan^2.
Received on 2009-03-05 10:22:29 CET