-
Notifications
You must be signed in to change notification settings - Fork 707
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
Improve Benchmarks for Pallet Election Provider Multiphase #446
Comments
One way of fixing this would be to add a new mechanism to the benchmarking machinery to introduce simple greater-than/less-than constraints between the components. For example, the benchmarks use these constants: const VOTERS: [u32; 2] = [1000, 2000];
const ACTIVE_VOTERS: [u32; 2] = [500, 800]; Obviously In one of the benchmarks we have this: let a in (T::BenchmarkingConfig::ACTIVE_VOTERS[0]) .. T::BenchmarkingConfig::ACTIVE_VOTERS[1];
let v = T::BenchmarkingConfig::VOTERS[1]; So we could add something like this to constraint these (imaginary syntax): let a in (T::BenchmarkingConfig::ACTIVE_VOTERS[0]) .. T::BenchmarkingConfig::ACTIVE_VOTERS[1] where a <= v; And then we could extend the bounds of the benchmarks, and the benchmarking machinery would only call the benchmark only in cases where Not sure if we actually want to do this, but it is a possibility. |
Somehow the FEPS weights were not updated in the last MR paritytech/substrate#12325 election-provider-support. Did you use the script or do it manually? |
@gpestana we can also now look into the cost of verifying an un-reduced solution. |
There are still a few benches which previously incorrectly generated with zero weights and/or now use the minimum times as the base weight and have one of their components start at a high number (mainly from
pallet_election_provider_multi_phase
), and I'd still like to do something about them (which is not trivial because the components' ranges cannot overlap for those benchmarks to correctly execute so you can't naively bring them down to zero), but looking at the numbers the minimums were bumped by only like 50%~70% so it's not the end of the world.Originally posted by @koute in paritytech/substrate#12325 (review)
The text was updated successfully, but these errors were encountered: