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