svn - but smaller?

[John Mehr]

On Fri, 12 Apr 2013 10:28:10 +0300
 Markiyan Kushnir <markiyan.kushnir at gmail.com> wrote:
> ok, looks like the mere fix to the strlen() call as you 
>suggested earlier doesn't resolve the issue of CPU eating 
>up.
> 
> On 12.04.2013 08:43, mrboco at gmail.com wrote:
>> On Friday, April 12, 2013 1:09:53 AM UTC+6, Markiyan 
>>Kushnir wrote:
>>>> Another thing that might be worth of attention, the 
>>>>patched version has
>>>> been again back to slower checkout time:
>>>> real    91m38.824s
>>>> user    0m26.216s
>>>> sys     0m13.858s
>>>> at 4 Mbit/s link, while the original 0.56 takes ~55min 
>>>>given the same
>>>> load/network conditions.
>>
>> You may just fix typo and not use other fixes. I doubt 
>>they actual for remote fetching.
> 
> I agree that that long update is not a critical problem 
>per se. People would set up a cron job to run svnup 
>regularly and not be bothered with it. However it might 
>become an inconvenience if one wants to update sources 
>ad-hoc, as for example during solving an issue. The thing 
>is that the proper time to check out a full base/head at 
>4Mbit/s is 7.5 minutes. And a subsequent update of the 
>tree is proportional to the amount of changes between the 
>revisions, and is often a matter of seconds. It would be 
>nice to get comparable time from svnup.
> 
> --
> Markiyan.
> 
>> _______________________________________________
>> freebsd-stable at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to 
>>"freebsd-stable-unsubscribe at freebsd.org"
>>
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to 
>"freebsd-stable-unsubscribe at freebsd.org"
> 

Hello,

In the previous version (0.61), the process of checking 
file names against the list of known files in the 
repository was inefficient and most likely accounts for 
the slow down you're seeing.  I've reimplemented it using 
a binary search tree and the lookup phase is no longer a 
bottleneck.