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

Weight v1.5: Opaque Struct #12138

Merged
merged 60 commits into from
Aug 31, 2022
Merged

Conversation

shawntabrizi
Copy link
Member

@shawntabrizi shawntabrizi commented Aug 29, 2022

This PR is an intermediate step between our current u64 Weight V1, and the upcoming multi-dimensional Weight v2.

This PR changes type Weight = u64 into struct Weight { ref_time: u64 }, and that is all.

This PR has a huge number of changes, but NONE of them should be logically different than before.

This will allow us to separate logical changes in the Weight V2 PR, from random syntax fixes.

polkadot companion: paritytech/polkadot#5943
cumulus companion: paritytech/cumulus#1581

Developer Notes

Look at the weight_v2.rs file to see the exposed APIs of struct Weight:

https://github.com/paritytech/substrate/blob/6b3a7d2115e7b6e31139e6860862d7d72bb0ed9e/frame/support/src/weights/weight_v2.rs

Here is some Regex find/replace which can help you migrate all your weight files:
Updated from comment of @al3mart #12138 (comment)

Find: \(([0-9_]+) as Weight\)\n
Replace: Weight::from_ref_time($1 as u64)\n

Find: _add\(\(([0-9_]+) as Weight\).saturating_mul
Replace: _add(Weight::from_ref_time($1 as u64).saturating_mul

Find: \(([0-9_]+) as Weight\)
Replace: ($1 as u64)

Find: \(([a-z]) as Weight\)
Replace: ($1 as u64)

Find: use frame_support::{traits::Get, weights::{Weight, constants::RocksDbWeight}};
Replace: use frame_support::{traits::Get, weights::{RefTimeWeight, Weight, constants::RocksDbWeight}};

@github-actions github-actions bot added the A0-please_review Pull request needs code review. label Aug 29, 2022
Copy link
Member

@ggwpez ggwpez left a comment

Choose a reason for hiding this comment

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

We also need to update all weights or?

frame/child-bounties/src/tests.rs Outdated Show resolved Hide resolved

use super::*;

pub type RefTimeWeight = u64;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the plan to eventually make this type private? Some docs would be nice here.

Copy link
Member Author

Choose a reason for hiding this comment

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

no, i think it will stick around. i added docs

Copy link
Member

@athei athei Aug 30, 2022

Choose a reason for hiding this comment

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

I am kind of allergic to primitive type aliases. I think we should either use the primitive type directly or crate a newtype struct RefTimeWeight(u64) with a Deref impl on it. Primitive type aliases are just the worst of both worlds: Adding cognitive load by making you look up another type but offer nothing in refactoring advantages as a newtype would do.

Copy link
Member Author

Choose a reason for hiding this comment

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

okay, i am happy enough to remove it in the next round

Copy link
Contributor

@KiChjang KiChjang Aug 31, 2022

Choose a reason for hiding this comment

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

Maybe a better way is to use a wrapper struct like @athei mentioned, but implement all the basic math traits on it like Add, Sub, Mul and Div instead of Deref, so that RefTimeWeight can act almost like a number.

Copy link
Member Author

Choose a reason for hiding this comment

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

i dont think we need to do that, u64 should be fine for a single field here.

The issue is only when the whole struct is represented as u64.

Copy link
Member

Choose a reason for hiding this comment

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

If we are relative sure that this type will never change, similar to Weight. I think keeping a type alias is fine. Type aliases are used are used to reduce cognitive load, not to increase it, imo. The point being that you directly know by reading what the types means and not need to find out where it comes from and what the function says about its usage.

Copy link
Member

Choose a reason for hiding this comment

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

Type aliases are used are used to reduce cognitive load, not to increase it, imo

The road to hell is paved with good intentions. I never felt they helped me. They just hide the truth from me and offer zero type safety. But I am not gonna die on that hill.

@paritytech-processbot
Copy link

Error: "Check reviews" status is not passing for paritytech/polkadot#5943

// AccountData for inner call origin accountdata.
.saturating_add(T::DbWeight::get().reads_writes(1, 1)),
.saturating_add(T::DbWeight::get().reads_writes(1, 1))
.saturating_add(dispatch_info.weight),
Copy link
Contributor

Choose a reason for hiding this comment

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

Does the ordering here really matter?

Copy link
Member Author

@shawntabrizi shawntabrizi Aug 31, 2022

Choose a reason for hiding this comment

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

no, this is left over from some other changes where it did matter, and then changes undone

Copy link
Member Author

Choose a reason for hiding this comment

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

should be superficial, so not gonna go back to fix

@shawntabrizi
Copy link
Member Author

bot merge

@al3mart
Copy link
Contributor

al3mart commented Sep 6, 2022

After the last iterations and changes related to this PR (see #12157), the regex provided on the description will look like:

Find: \(([0-9_]+) as Weight\)\n
Replace: Weight::from_ref_time($1 as u64)\n

Find: _add\(\(([0-9_]+) as Weight\).saturating_mul
Replace: _add(Weight::from_ref_time($1 as u64).saturating_mul

Find: \(([0-9_]+) as Weight\)
Replace: ($1 as u64)

Find: \(([a-z]) as Weight\)
Replace: ($1 as u64)

@louismerlin louismerlin added D1-audited 👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited and removed D9-needsaudit 👮 PR contains changes to fund-managing logic that should be properly reviewed and externally audited labels Oct 13, 2022
ark0f pushed a commit to gear-tech/substrate that referenced this pull request Feb 27, 2023
* initial idea

* update frame_support

* update a bunch more

* add ord

* adjust RuntimeDbWeight

* frame_system builds

* re-export

* frame_support tests pass

* frame_executive compile

* frame_executive builds

* frame_system tests passing

* pallet-utility tests pass

* fix a bunch of pallets

* more

* phragmen

* state-trie-migration

* scheduler and referenda

* pallet-election-provider-multi-phase

* aura

* staking

* more

* babe

* balances

* bunch more

* sudo

* transaction-payment

* asset-tx-payment

* last pallets

* fix alliance merge

* fix node template runtime

* fix pallet-contracts cc @athei

* fix node runtime

* fix compile on runtime-benchmarks feature

* comment

* fix frame-support-test

* fix more tests

* weight regex

* frame system works

* fix a bunch

* more

* more

* more

* more

* more

* more fixes

* update templates

* fix contracts benchmarks

* Update lib.rs

* Update lib.rs

* fix ui

* make scalar saturating mul const

* more const functions

* scalar div

* refactor using constant functions

* move impl

* fix overhead template

* use compactas

* Update lib.rs
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. C1-low PR touches the given topic and has a low impact on builders. D1-audited 👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

10 participants