Re: merge very slow

Lieven Govaerts wrote:
> Stefan Küng wrote:
>> Hi,
>>
>> I've noticed that a merge done with a client built with VS2008 is
>> twice as slow as a client built with VC6. Has anyone here noticed that
>> too?
>> I've described my efforts to solve this problem here:
>> http://tortoisesvn.tigris.org/servlets/ReadMsg?list=dev&msgNo=34103
>>
>> If anyone has any idea what could cause this, I'd really appreciate
>> any help.
> The obvious question first: you are using a Release build of course?
>
> Concerning profiling, IBM has a 15-days trial edition of Rational
> PurifyPlus at their website:
> http://www-306.ibm.com/software/awdtools/purifyplus/
> I've never used it (well, not in the last 10 years), but at first sight
> it should allow you to profile different builds of svn.

Sure, but it requires to have the app built with purifyplus installed.
And my problem is that I can't do that with VC6 since I don't have it.

> With every release of VS comes a new version of the CRT. I wouldn't be
> surprised of some of the improvements it brings are in fact downgrading
> performance in the algorithms used in 'svn merge'. While it could be
> networking related, it could be slower memory block allocation etc.
> How does svn 1.4.6 compare in merge time in VC6 vs VS2008?

I guess many people will get really annoyed/angry with the 1.5 release
of Subversion. I've ran some tests with different builds, all tests done
with the command line:
svn merge -r11761:11762
http://tortoiosesvn.tigris.org/svn/tortoisesvn/branches/1.4.x --dry-run

(for the 1.5 clients, I also added '--accept postpone' to the command line).

Here are my results:

my build from 1.5.x branch, built with VS2008:
5:17 .. 5:34

1.5.0-RC9 from open.collab.net:
2:22 .. 2:50

1.4.6 client:
0:12 .. 0:15

Which means a simple merge that took a few seconds with an 1.4 client
now takes minutes!
(the numbers above are minutes:seconds)

Since I've been trying to optimize/tweak my build for more than two days
now, I can tell you what I found so far:

The delays happen because (at least on Windows) a 'connect' is
expensive. It seems that a build with VS2008 adds some more sanity check
code for those calls which makes those take a few miliseconds longer
than a build with VC6.
Most svn commands only connect once or twice to the repository, that's
why most people never had performance problems with an 1.5.x build
(those who don't do merging but only use checkout/commit/update/log).

But a merge command loops over all merge ranges, connecting several
times for each range. If it would re-use the connection it already has,
it would be *much* faster, maybe almost as fast as an 1.4.x client.

* Serf is twice as fast as neon for merges, but only if IPv6 support is
disabled.
* ra_neon exchanges the capabilities for *every* connect, which means
that's done several times for one single merge (i.e., a lot of data sent
over the wire with no benefit at all)
* ra_svn is much faster than ra_neon/ra_serf, but the same here: with
IPv6 enabled it takes twice as long
* IPv6 has no (or almost no) impact on ra_neon when doing a merge. Of
those 5 and a half minutes, the gain by disabling IPv6 is around 10 seconds

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net