Open kianenigma opened 1 year ago
I've been looking into starting this and I have a few questions / assumptions.
Out of the 3 options, I have planning on doing the first one as it seems like a great way to start learning about how the construct_runtime
macro works, but imk if you guys prefer one of the other ways.
This can happen as a separate test that lives inside
construct_runtime
By inside of construct_runtime
do you guys mean some sort of check in this macro? This is the only thing I could think of, but it seems like you guys wouldn't want to touch this as it is such a core piece of code.
https://github.com/paritytech/substrate/blob/0cbea5805e0f4edcf8a3a70135b4d8eabc2db06f/frame/support/procedural/src/construct_runtime/mod.rs#L231-L250
We really should have the benchmark data stored in a proper data file format such as csv and then use the csv file to generate weight file. And then can also do whatever additional checks from the csv file directly without all the complicated Rust changes.
@jtfirek are you still working on it? Otherwise I'd like to do it!
Moreover, an extensive list of weight functions is also known
I want to clarify that I am pretty sure this information is available, but I can't recall the exact trait that would return it. I will post it here if I find it, as it would be the starting point of this issue. @ggwpez maybe you know it in your 🧠? :D
@Daanvdplas feel free to ask questions if you have any!
Daan asked me about it and seems to be on his way 😄
The current approach will print the warning when running the CLI, not as part of construct_runtime!
.
In any given FRAME based runtime, the total block weight is known. Moreover, an extensive list of weight functions is also known. Most often, each weight function corresponds to a single dispatchable, or a single hook. If not, it almost always refers to a subset of them.
We also know that the entire weight system is linear.
Given these two points, it is fair to assume that the following is possibly a mis-configuration of the runtime.
This can happen as a separate test that lives inside
construct_runtime
, an independent opt-in test, or seemingly best, happen as a part of the benchmark execution where the component ranges is known, and we don't need to fallback toBounded::min_value
.