Update treasury weights.

[gui1117]

Also fix: #5706

• added ContainsLengthBound for election-phragmen
• numbers comes from https://www.shawntabrizi.com/substrate-graph-benchmarks/?p=treasury&e=tip_new
  I then keep 2 digits by shifting up (111 -> 12)

polkadot PR: paritytech/polkadot#1044

[shawntabrizi]

I liked your suggestion to include the raw data with the weight paragraph. I also think it was suggested we choose "round" numbers for weights, but maybe we should double check with others.

I would write a weight of:

 #[weight = 200_000_000 + 1_000_000 * MAX_TIPPERS_COUNT + T::DbWeight::get().reads_writes(3, 3)] 

If I was doing this.

[gui1117]

it improves readibility but rounding 211 to 200 is 5% and 1_094 to 1_000 is 10%. I feel like its fine to just put the direct value with useless precision.

I rounded a bit.

[gui1117]

I kept 2 significative digits for each and rounded up to get them
https://en.wikipedia.org/wiki/Significant_figures

[kianenigma]

so can you bring me up to speed, where are these numbers coming from? the 114_700_000 per se.

[kianenigma]

• to me it seems like we ignore sender account all the time here. Correct? Also best to call it origin in the doc as well.

[gui1117]

this number directly comes from the benchmark server at https://www.shawntabrizi.com/substrate-graph-benchmarks/?p=treasury&e=tip_new

[gui1117]

for all coefficient I kept 2 digits by rounding up.

[apopiak]

for all coefficient I kept 2 digits by rounding up.

Just want to note that I saw changes of up to 30% in benchmark time component estimations between runs on Monday and Tuesday. It mostly seemed to shift between constant and parametrized components, but it still lead to me being more conservative (i.e. choosing higher) with my values.

[gui1117]

for all coefficient I kept 2 digits by rounding up.

Just want to note that I saw changes of up to 30% in benchmark time component estimations between runs on Monday and Tuesday. It mostly seemed to shift between constant and parametrized components, but it still lead to me being more conservative (i.e. choosing higher) with my values.

oh ok, that is a bit surprising to me though, the machine wasn't use for anything else ?

EDIT: we could keep indeed only one or one with 0.5 digits but this sounds very unprecise like 1.1->1.5 is 36% change.

[shawntabrizi]

for all coefficient I kept 2 digits by rounding up.

Just want to note that I saw changes of up to 30% in benchmark time component estimations between runs on Monday and Tuesday. It mostly seemed to shift between constant and parametrized components, but it still lead to me being more conservative (i.e. choosing higher) with my values.

oh ok, that is a bit surprising to me though, the machine wasn't use for anything else ?

EDIT: we could keep indeed only one or one with 0.5 digits but this sounds very unprecise like 1.1->1.5 is 36% change.

The error comes from the analysis I think more than the individual runs. When there is no attribution of the weight to other components, it seems the results are quite stable.

Although, this has not been tested thoroughly.

[gavofyork]

polkadot companion still not building?

[gui1117]

yes done

[gui1117]

Flag has been changed to merge-once-green but actually this still lack an approve flag @gavofyork