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.
For this kind of analysis I'd very strongly recommend Intel's VTune over
Quantify. VTune is a sampling profiler that doesn't affect the programs
execution speed much -- and thus leaves the interaction between program,
runtime lib and network stack pretty much unchanged. Quantify is
horrible on I/O bound tests because it totally changes all
timing-related effects.
>> 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.
Oh duh. A few extra milliseconds on modern hardware? What, are they
doing a virus scan on the data? As if the networks stack on Windows
wasn't already rotten enough.
> 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.
I wonder if this is even an option ... opinions, anyone?
> * 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
The svnserve protocol is stateful, and doesn't have all the HTTP/DAV
cruft, so it's not surprising that it's faster.
> * 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
This pretty much points at an IPv6-related problem in APR -- since Neon
doesn't use APR for its network layer, while Serf and ra_svn do.
-- Brane
---------------------------------------------------------------------
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 12:56:55 CEST