-
Notifications
You must be signed in to change notification settings - Fork 768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic weight sanity checker #152
Comments
I've been looking into starting this and I have a few questions / assumptions.
|
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! |
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 😄 |
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
.The text was updated successfully, but these errors were encountered: