Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Calculate and refund weight for identity pallet #5680

Merged
merged 39 commits into from Apr 24, 2020
Merged

Conversation

apopiak
Copy link
Contributor

@apopiak apopiak commented Apr 17, 2020

This PR implements weight calculation and refund for the dispatchables in pallet-identity.

Changes:

  • add more sophisticated weight calculation to all the dispatchables and refunds to some of them
  • fix set_subs benchmark (to contain 2 parameters).
  • limit registrars in add_registrar to new MaxRegistrars (new error TooManyRegistrars)

API Notes:

  • No notable changes to the dispatchables API (only the return value changed to DispatchResultWithPostInfo)

Drive-by Changes:

  • some small docs adjustments (for benchmarking)
  • convert an addition to saturating_add because it was failing a test

Related to #5596

@parity-cla-bot
Copy link

It looks like @apopiak signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

@apopiak apopiak requested a review from thiolliere April 23, 2020 13:19
@apopiak apopiak marked this pull request as ready for review April 23, 2020 14:25
@apopiak
Copy link
Contributor Author

apopiak commented Apr 23, 2020

Does the PR need a Polkadot companion if it doesn't change the parameters and only the return type of the Dispatchables?

@apopiak apopiak changed the title Improve weight estimation for identity pallet Calculate and refund weight for identity pallet Apr 23, 2020
@apopiak
Copy link
Contributor Author

apopiak commented Apr 23, 2020

Never mind, I need to add MaxRegistrars of course 🤦

@apopiak apopiak added the A0-please_review Pull request needs code review. label Apr 23, 2020
@@ -69,6 +69,9 @@ pub use paste;
/// (or not) by each arm. Syntax is available to allow for only the range to be drawn upon if
/// desired, allowing an alternative instancing expression to be given.
///
/// Note that the ranges are *inclusive* on both sides. This is in contrast to ranges in Rust which
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a follow up, we can just change the macro syntax to MIN ..= MAX, which I also think solve this syntax mismatch right?

extra_fields: impl Into<Weight>
) -> Weight {
db.reads_writes(1, 1)
+ db.reads_writes(1, 1) // balance ops
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be excluded because balance read/write targets the System.Account storage item, which will already be updated this block because a user submitted an extrinsic, and their nonce/fee will be charged.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for the other balance operations in this PR. It would only apply if the user whose balance is changing is NOT the caller.

extra_fields: impl Into<Weight>
) -> Weight {
db.reads_writes(3, subs.into() + 3) // 2 `take`s + S deletions
+ db.reads_writes(1, 1) // balance ops
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This case balance op is correct

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But you seem to be missing a write to the treasury account (which I think you would skip anyway since treasury is written to every block, but for further analysis, would be good to double check why you might have missed treasury)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should have noted that the I could not account for 1 read and 1 write in the first line.
You think that might be the treasury? Where does it come in? Through Slashed::on_unbalanced?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you can see the configuration in the Node runtime, but also you can see it in our DB logs

Copy link
Contributor Author

@apopiak apopiak Apr 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the benchmark says there are 4 reads and subs + 4 writes.
I'm happy to subtract 1 for the balance op, but I don't know how to trace whether the treasury one is a duplicate. With "DB logs" do you mean the logs under the DB benchmark? How would I tell that it's the treasury? Is it a special address?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added treasury to our "whitelist" so it should show up now explicitly in the name and remove itself automatically from the read count.

The way I figured it out is that i used the DB logs and walked through the code to identify each read/write operation on the DB log with some code that was written.

I suggest you do the same

subs: impl Into<Weight> + Copy,
extra_fields: impl Into<Weight>
) -> Weight {
db.reads_writes(3, subs.into() + 3) // 2 `take`s + S deletions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be 2 instead of 3?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be the treasury ops you noted above?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, but this should be 2 for both read and write

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, you're right

Copy link
Contributor

@shawntabrizi shawntabrizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some feedback, but everything else looks good here!

Copy link
Contributor

@shawntabrizi shawntabrizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks right.

I guess my last worry would be any chances of overflow in the weight math.

Some of these values are directly controllable by the end user right?

Copy link
Contributor

@shawntabrizi shawntabrizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@shawntabrizi shawntabrizi added A8-mergeoncegreen and removed A0-please_review Pull request needs code review. labels Apr 24, 2020
@gnunicorn gnunicorn merged commit 66960eb into master Apr 24, 2020
@gnunicorn gnunicorn deleted the apopiak-weight-params branch April 24, 2020 14:47
@apopiak apopiak mentioned this pull request Apr 24, 2020
lamafab pushed a commit to lamafab/substrate that referenced this pull request Jun 16, 2020
* Companion PR for paritytech#5501

* Bump runtime versions

* add MaxRegistrars config

* Pull substrate master in PR-5501

* Attempt to fix pin commit again

* update to substrate master

Co-authored-by: Alexander Popiak <alexander.popiak@parity.io>
Co-authored-by: André Silva <andre.beat@gmail.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants