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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to