Updated weights for v900 release

[gilescope]

notable changes:

• batch_all has db read and write added. (There don't seem to be any changes to the utilities pallet in substrate).

• remark_with_event has flipped to weight 0 on polkadot. (I'm fine with this as the extrinsic length is where the remark fee is charged.)

Everything else looks pretty tight - not much change from last time.

[NachoPal]

I can not find either a explanation for the extra read/writes for batch_all

[gilescope]

Problemo: https://github.com/paritytech/cumulus/tree/giles-update-weights/polkadot-parachains/statemint/src/weights

If you look at that url you can see that not all the weights files were updated.

[NachoPal]

Problemo: https://github.com/paritytech/cumulus/tree/giles-update-weights/polkadot-parachains/statemint/src/weights

If you look at that url you can see that not all the weights files were updated.

What do you mean? we are running the benchmarks for 11 pallets and I see in the PR that 33 files were changed, which make sense since we have 3 runtimes.

[gilescope]

So talking with Oliver, the not updated weights files basically have been fixed since year dot.
The block_weights.rs and extrinsics_weights.rs will be able to be benchmarked by the command benchmark overhead but this is not exposed yet to polkadot-collator. (Hopefully by the next release we can start autogening those).

The paritydb and rocksdb files need a bit more thought as to how they get autogened as "it basically needs to create inherents, signed extrinsics and a transaction in a somehow runtime agnostic way".

Oliver has kindly documented this all here: paritytech/substrate#11246

So I think there's no reason not to merge what we have and look forward to an expanded benchmarking scope for next release.

[gilescope]

batch_all has db read and write added. - we note that polkadot had the same added and was approved: https://github.com/paritytech/polkadot/blob/1d6660fc484bcad9756424708de4c3271e2eada5/runtime/polkadot/src/weights/pallet_utility.rs#L60

[ggwpez]

For posterity:
The DB accesses in batch_all most likely come from the fact that we changed the transactional layer to be saved in storage now. Introduced here I think paritytech/substrate#10808.
This incurs additional read/writes.