Stefan Küng wrote:
> 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.
Hm, it'd have to be a bit more than a few milliseconds per connect.
So what you're saying is that svn merge 1.4 is ten times faster than svn
merge 1.5/VC6, which on its turn is two times faster as svn merge
1.5/VS2k8 right?
Do you have the option to return to VS2k5 for TSVN? That doesn't solve
the general slowdown (see below), but at least TSVN is than equally slow
as svn - assuming that VS2k5 has the same performance characteristics as
VC60.
> 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.
I did a merge from a range of revisions of svn /trunk to a svn 1.5
working copy with a trunk svn and ra_serf. This is the result:
Nr. of opened sessions: 7
Nr. of reports sent to the server: 149
Nr. of opened sockets: 241
This was a debug build, so the total time is not really important.
The difference in nr. of reports and nr. of sockets is the fact that
ra_serf opens more than one socket per report, in order to send multiple
requests in parallel.
Anyway, no less than 241 sockets is way to high. It should be possible
to reuse those sockets more, but this should be solved in the ra layers.
I'll have a look at ra_serf to see what we can do.
> * 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
Isn't apr following a 'connect over ipv6' -> timeout -> 'retry over
ipv4' scheme?
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-15 14:43:15 CEST