Re: merge very slow

On Sun, Jun 15, 2008 at 5:42 AM, Lieven Govaerts <svnlgo_at_mobsol.be> 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.
>>
>>> 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
Bah! That's awfull. IMHO it could be showstopper of 1.5.x :(

>> * 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.
>
Reusing sockets in ra layers is bad idea. It's will be very implicit
behavior, so problem will just hide one more level deeper.

I've looked to merge.c code and I've shocked: we create many ra
sessions when merging. This is source of all slowdowns. And also there
is no comments why we doing so. Could someone explain why we creating
new sessions instead of reusing?

-- 
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org