Re: svn - but smaller?

On Fri, 12 Apr 2013 10:28:10 +0300
=A0Markiyan Kushnir <markiyan.kushnir@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@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=A0=A0=A0=A091m38.824s
>>>> user=A0=A0=A0=A00m26.216s
>>>> sys=A0=A0=A0=A0 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@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to =

>>"freebsd-stable-unsubscribe@freebsd.org"
>>
> =

> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to =

>"freebsd-stable-unsubscribe@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.=A0 I've reimplemented it using =

a binary search tree and the lookup phase is no longer a =

bottleneck.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"