[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merge very slow

From: Branko Čibej <brane_at_xbc.nu>
Date: Sun, 15 Jun 2008 23:30:27 +0200

Stefan Küng wrote:
> Branko Čibej wrote:
>> 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.
> Thanks for the hint.
> I've installed and tried both. I couldn't get much usable data from
> both: it's not a CPU issue. The CPU usage stays at almost 0% during
> the whole merge.

That looks like something hanging for a timeout when the connection is
being made. My best guess: APR with IPv6 enabled tries a v6 connection
first, regardless of whether the network stack itself supports IPv6
(i.e. if the protocol driver is installed), and/or even if the resolved
address is IPv4. Now it's time to dig into the APR sources ...

> And I had to use a restore point to get rid of those tools again. I've
> rarely seen such intrusive applications!

Well, the most intrusive application I've ever seen is Windows, it took
me ages to get a box without it and it still lives on in a virtual
machine on this Mac. :)

>>> 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.
> My hardware is quite good:
> T7500_at_2.20GHz, 4GB RAM
> So that's definitely not an issue.

No no, you misunderstood -- I mean that a few milliseconds on modern
hardware is a *huge* amount of time. Really totally unacceptable.

> Also, it doesn't help to rant about the Windows network stack. If you
> like it or not, many people have to live with it and are quite happy.
> Other applications can deal with it well enough.

Hey, I'm trying to help with a Windows issue, surely I'm allowed the
occasional rant? :)

-- 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 23:31:17 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.