subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@wandisco.com>
Subject Re: svn commit: r1701317 - in /subversion/trunk/subversion: include/private/svn_ra_svn_private.h libsvn_ra_svn/marshal.c
Date Sat, 05 Sep 2015 21:19:56 GMT
On 05.09.2015 18:53, Ivan Zhakov wrote:
> On 5 September 2015 at 19:23, Branko Čibej <brane@wandisco.com> wrote:
>> On 05.09.2015 02:53, Branko Čibej wrote:
>>> On 04.09.2015 21:17, stefan2@apache.org wrote:
>>>> Author: stefan2
>>>> Date: Fri Sep  4 19:17:44 2015
>>>> New Revision: 1701317
>>>>
>>>> URL: http://svn.apache.org/r1701317
>>>> Log:
>>>> Finally, make svn_ra_svn__list_t actually a fully typed, ra_svn-specific
>>>> object.  Update the creation functions; everything else already "just fits".
>>> How is this code different from using APR arrays, except that the latter
>>> needs a typecast on array item access? As far as I can see, you've
>>> completely duplicated the APR array allocation strategy, including using
>>> two allocations to create the array.
>>>
>>> The only significant difference is that capacity is being tracked
>>> outside the svn_ra_svn__list_t structure during the construction of the
>>> list.
>>>
>>> Call me dense ... but can you please explain how exactly is this
>>> better/faster than using APR arrays? (I'm not going to mention 'safer'
>>> because it clearly isn't.) Code like this that is apparently meant be an
>>> optimisation of something(?) really should have a bit of an explanatory
>>> comment, IMO.
>> I played around with the apr_array_make implementation a bit and did
>> some performance measurements with small array allocation and usage,
>> with the following pattern:
>>
>>   * in 60% of cases, the array does not get resized
>>   * in 30% it gets resized once
>>   * in 10% it gets resized twice
>>
>> If I change apr_array_make to allocate the initial number of elements in
>> the same block as the array header, I get a 15% speedup on this test
>> case, compared to the default implementation. If I change it further to
>> never set the element values to 0 in apr_array_make, I get an additional
>> 10% speedup, for a total of 23%. So I'm guessing this is the number you
>> were actually seeing.
> Is it speedup of overall Subversion over svn:// protocol operation or
> just of APR array allocation?

Stefan reported a 20% speedup of svn:// protocol processing. My test
case doesn't measure that, of course.

-- Brane


Mime
View raw message