Adding benchmarking for new frame_election_provider_support

[georgesdib]

Fixes #11111

Created a benchmarking pallet for frame-election-provider-support, namely SequentialPhragmen and PhragMMS.
Few changes to onchain.rs as well and making the trait always bounded, and adding WeightInfo.

Refactoring #11126

Polkadot companion: paritytech/polkadot#5241
skip check-dependent-cumulus

Polkadot address: 131dPecTmpTC1p1ofemufqFBJo9vNbV7dkgN7vWwKnaSMkC4

[kianenigma]

I have some minor feedback as well, but I am going to save that until this major flaw is solved: the purpose of this pallet is to benchmark these election algorithms alone and isolated. The reason for this is that currently the ElectionDataProvider trait specifies that its implementors need to be self-weighing and register their own weight. With that out of the way, we need to only benchmark T::Solver::solve() to have some kind of a realistic measure.

[kianenigma]

Here's some random feedback and how I think this should work out, but this does not compile yet and has some TODOs. If you agree with the overall direction, the branch can be a good guideline:

https://github.com/georgesdib/substrate/pull/new/kiz-onchain-election-benchmarking

Lastly:

For now, we have VotersBound and TargetsBound as being part of ConfigParams which is normally implemented for Runtime. However, ideally these 2 types should be part of the ElectionDataProvider trait as they are really a property of the data provider. This could be worked on in a separate PR with a big ensuing refactoring.

A VoterBound on ElectionDataProvider has the meaning of: what is the maximum number of voters that this data provider can provide (which I don't think we ever need to bound)

A VoterBound on onchain::Config has the meaning of: how many voters should this implementation of onchain::Config ask from its ElectionDataProvider?

TLDR; I think VotersBound on onchain::Config makes good sense :)

[kianenigma]

\tip large

[kianenigma]

\tip large

[emostov]

LGTM - thanks

[kianenigma]

/tip large

[kianenigma]

/tip large

[kianenigma]

\tip large

[kianenigma]

Okay, I will open a manual tip for you @georgesdib.

[kianenigma]

bot merge

[paritytech-processbot]

Error: pr-custom-review is not passing for paritytech/polkadot#5241

[kianenigma]

bot merge

[paritytech-processbot]

Error: pr-custom-review is not passing for paritytech/polkadot#5241

[kianenigma]

bot merge

[paritytech-processbot]

Error: pr-custom-review is not passing for paritytech/polkadot#5241

[kianenigma]

bot merge

[paritytech-processbot]

Error: pr-custom-review is not passing for paritytech/polkadot#5241

[kianenigma]

bot merge

[ggwpez]

You skipped the cumulus check, somehow my cumulus CI errors with:

error[E0432]: unresolved import `frame_election_provider_support::onchain::ExecutionConfig`
  --> /usr/local/cargo/git/checkouts/polkadot-4038f27d5e4ea2e8/3ff2b83/runtime/common/src/elections.rs:20:12
   |
20 |     onchain::{ExecutionConfig, UnboundedExecution},
   |               ^^^^^^^^^^^^^^^ no `ExecutionConfig` in `onchain`

Could this be related @georgesdib ?

[georgesdib]

You skipped the cumulus check, somehow my cumulus CI errors with:

error[E0432]: unresolved import `frame_election_provider_support::onchain::ExecutionConfig`
  --> /usr/local/cargo/git/checkouts/polkadot-4038f27d5e4ea2e8/3ff2b83/runtime/common/src/elections.rs:20:12
   |
20 |     onchain::{ExecutionConfig, UnboundedExecution},
   |               ^^^^^^^^^^^^^^^ no `ExecutionConfig` in `onchain`

Could this be related @georgesdib ?

Isn't this in from the polkadot codebase? The companion PR is now merged, perhaps the above was run after the substrate PR was merged but not the polkadot PR?

[ggwpez]

Yes sorry, I think the dependencies just got messed up. Thanks for you contributions!