Adding migration instruction from benchmarking v1 to v2 #6093
Conversation
re-gius
added
the
T1-FRAME
|
Review required! Latest push from author must always be reviewed |
There was a problem hiding this comment.
Great summary!
There's a construct from v1 that doesn't exist in v2 whose refactoring would be nice to describe here, but I don't know how it can be done in the general case.
In v1 of the benchmarking pallet, there exists a macro named selected_benchmark, which is used to create a SelectedBenchmark enum, which will contain all of the benchmarks defined inside benchmark! as variants.
From this enum we can access a specific benchmark to e.g. run it as a unit test.
Here are examples: https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/benchmarking/src/tests.rs#L256
In #6018 there was no code using it, but in #6025, there was one occurrence - which luckily could just be removed.
Doing a code search on SelectedBenchmark over the entire polkadot-sdk shows it is used in:
frame-benchmarkingitself (src/tests.rs,src/v1.rs)frame-supportframe-benchmarking-cli
I doubt moving the above pallets/crates to v2 is a high-priority task, so describing how to migrate SelectedBenchmark can be done at a later time.
| /// 1. Change the import from `frame_benchmarking::v1::` to `frame_benchmarking::v2::*`, or | ||
| /// `frame::benchmarking::prelude::*` under the umbrella crate; | ||
| /// 2. Move the code inside the v1 `benchmarks! { ... }` block to the v2 benchmarks module `mod | ||
| /// benchmarks { ... }` under the benchmarks macro (`#[benchmarks]` or `#[instance_benchmarks]`); |
There was a problem hiding this comment.
Maybe worth explaining briefly why you'd use one or the other as you did for #[extrinsic_call] vs #[block].
Co-authored-by: Dónal Murray <[email protected]>
Co-authored-by: Dónal Murray <[email protected]>
Co-authored-by: Dónal Murray <[email protected]>
Adding instruction to migrate benchmarking from v1 to v2
Even if the documentation for benchmarking v1 and v2 is clear and detailed, I feel that adding a migration guide from v1 to v2 would help doing it quicker.
Integration
This change only affects documentation, so it does not cause integration issues.
Review Notes
I followed the migration procedure I applied in PR #6018 . I added everything from there, but I may be missing some extra steps that are needed in specific case, so in case you notice something please let me know.