On 5 September 2015 at 19:23, Branko Čibej <brane_at_wandisco.com> wrote:
> On 05.09.2015 02:53, Branko Čibej wrote:
>> On 04.09.2015 21:17, stefan2_at_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?
--
Ivan Zhakov
Received on 2015-09-05 18:53:47 CEST