On 05.09.2015 18:53, Ivan Zhakov wrote: > On 5 September 2015 at 19:23, Branko Čibej <br...@wandisco.com> wrote: >> On 05.09.2015 02:53, Branko Čibej wrote: >>> On 04.09.2015 21:17, stef...@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
