[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: more benchmarks: comparing runtime of 1.6.x vs. trunk aka 1.7 / wc-ng

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Thu, 23 Sep 2010 23:59:51 +0200

On 2010-09-23 16:24, Julian Foad wrote:
> Hi Neels.
>
> The "svn --version" ratio shows wild variation in the "max" and "avg"
> columns across different data sets, while its ratio in the "min" column
> stays around 1.0 as expected. There isn't any explanation for this
> apart from timing errors is there?
>
> - Julian

yeah, it does that because it takes such short time. A timing unlinearity
then has humungous effect on the factor. The --version timing is just an
artefact produced by the simplicity of the py script. Ignore.

svn resolved and propset are also such candidates. Note that propset also
takes a very short time. 'resolve' and 'resolved' interestingly enough seem
to be slight exceptions from this rule.

There were massive amounts of propsets in the test, so the propset data
should be fairly noiseless compared to --version, which was measured only
once per run. Oh, I should maybe give the number of runs too...

[[[
4x4_1.7_all.runs
count min max avg operation (min/max/avg unit is *seconds*)
   84 0.168 1.278 0.335 status
   12 0.197 1.178 0.350 resolved
   12 0.011 0.014 0.013 resolve
 2316 0.013 0.073 0.015 propset
  100 0.013 0.026 0.015 mkdir
   90 0.082 1.812 0.636 update
    6 0.009 0.025 0.012 --version
   12 1.857 2.640 2.225 merge
    6 0.904 1.008 0.960 switch
  106 0.013 0.355 0.033 add
   28 0.013 0.028 0.015 propdel
 1114 0.011 0.031 0.013 proplist
   48 1.592 3.633 2.536 commit
  578 0.013 0.064 0.015 prop mod
   12 0.035 1.773 0.846 checkout
    6 0.368 0.436 0.391 copy
    6 0.509 0.564 0.524 delete
    6 53.047 56.503 54.242 TOTAL RUN
]]]

>> 4x4: WC is 4 dir-levels deep and each subdir 4 dirs wide, plus each subdir
>> has 4 files:
>>
>> 4x4_1.7_all.runs / 4x4_1.6_all.runs
>> min max avg operation (unit is factor between runs)
>> 5.686 6.093 5.203 status
>> 4.739 20.004 6.958 resolved
>> 1.088 0.348 0.896 resolve
>> 1.163 0.279 1.113 propset
>> 1.132 1.066 1.108 mkdir
>> 2.369 1.237 1.523 update
>> 0.914 0.246 0.477 --version
>> 2.238 2.025 2.258 merge
>> 1.463 1.389 1.409 switch
>> 1.223 1.168 1.273 add
>> 1.131 1.816 1.170 propdel
>> 1.140 1.000 1.112 proplist
>> 1.464 1.637 1.684 commit
>> 1.174 1.797 1.173 prop mod
>> 1.610 1.884 1.948 checkout
>> 0.891 0.725 0.819 copy
>> 1.992 2.114 2.019 delete
>> 1.663 1.532 1.625 TOTAL RUN
>>
>> -> svn status, resolved, merge and checkout suck hard, with multiples of the
>> 1.6.x run time.
>> -> is that an improvement there for svn copy? (it's a wc->wc copy)
>> -> everything else has the tendency to suck, getting up to 50% slower.
>> (-> svn resolve and propset (initial creation of a prop) have very low
>> factors for the 'max' column -- seems to suggest that 1.6.x had much higher
>> variation on resolve and propset run times than trunk. -- milkin' it.)

Looking forward to optimisations and to seeing the numbers shrink :)

~Neels

Received on 2010-09-24 00:00:43 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.