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?
-- Ivan Zhakov
