Re: merge very slow

On Sun, Jun 15, 2008 at 6:22 AM, Stefan Küng <tortoisesvn_at_gmail.com> 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.
> 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.

Merge in 1.5 has to crawl the working copy, and I am pretty sure that
1.4 did not. So while I am sure it could be made faster by
implementing your suggestions, I do not think it can get down to the
same times as 1.4. At least not on Windows where the working copy
crawl is so slow.

Out of curiosity, what are your timings for svn status on your working
copy? I'd expect them to be a lot faster than the ones I posted. In
the tests I did, merge was only 10-12 seconds slower than status. But
as I pointed out, I was running them in a scenario with high bandwidth
and low latency.

I think it would be interesting to see if VS 2008 has added any time
to svn status though. My tests with the VC6 build of Subversion
showed that merge time could be attributed primarily to the status
crawl.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org