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