-
Notifications
You must be signed in to change notification settings - Fork 361
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
feat: add xcm benchmarks #1129
feat: add xcm benchmarks #1129
Conversation
/bench shibuya-dev xcm_benchmarks_generic,xcm_benchmarks_fungible |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/7476342157. |
/bench shibuya-dev xcm_benchmarks_generic,xcm_benchmarks_fungible |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/7477119023. |
/bench shibuya-dev xcm_benchmarks_generic,xcm_benchmarks_fungible |
Benchmarks have been finished. |
/bench shibuya-dev xcm_benchmarks_generic,xcm_benchmarks_fungible |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/7478071828. |
/bench shibuya-dev xcm_benchmarks_generic,xcm_benchmarks_fungible |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/7478138231. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked some of the instructions, just to see why certain weights were measured. But I'll probably do more later before the merge. All looks good to me so far.
Just one question about the approach to reuse.
/// We need re-write buy_execution benchmark becuase our runtime | ||
/// needs 1 additional DB read (XcAssetConfig) for fetching unit per sec | ||
/// for a fungible asset. The upstream benchmark use native assets thus | ||
/// won't accout for it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One general question about this approach - how viable is to reuse code from the official repo if we have to account for different actions for some calls?
This can change in the future, upstream, and it means we should be re-checking all of the benchmarks each time we do an uplift?
It would seem easier to just have all the benchmarks in our repo since that way we have full control over it. If I understood the current approach correctly, it's highly likely we miss something in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The upstream benchmarks are quite generic themselves, but not generic enough maybe because not many parachains are using them.
The benchmarks we had to re-write were only due the use of hardcoded native asset inside some benchmarks.
- buy_execution: hardcoded native asset used for buying execution
- transfer_*: does not take ED into account, they use native asset (pallet_balances) which defaults to allow death unlike fungibles (
pallet_assets
). - expect_pallet: hardcoded pallet index
Other than that all benchmarks were configurable through the pallet's Config. As long as we we used same release upstream pallet (XcmConfig
is not changed) it should be fine.
For the hardcoded cases, we can make a upstream PR to make it more generic for other parachains to use as well.
I'm fine either ways, if we copy-paste all benchmarks then we need to keep them updated during uplift if there are major changes like precompile-utils
and if we don't copy-paste then we still need to check them during uplifts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation!
Let's keep it like this, as you suggested.
For the upstream PR, let's start with an issue first perhaps?
fn reserve_asset_deposited() -> Weight { | ||
// Proof Size summary in bytes: | ||
// Measured: `0` | ||
// Estimated: `0` | ||
// Minimum execution time: 3_440_000 picoseconds. | ||
Weight::from_parts(3_603_000, 0) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added manually?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I meant added (copy-pasted) the benchmark itself from pallet-xcm-benchmark
v1.x.x release not the weights
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, but I asked because there are no docs above the function like the others 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that is because ReserveAssetDeposited
does not use touch storage and just put asset into holding thus purely ref_time based computation therefore no storage access logs above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -53,6 +53,7 @@ use pallet_xc_asset_config::{ExecutionPaymentRate, XcAssetLocation}; | |||
mod tests; | |||
|
|||
pub const XCM_SIZE_LIMIT: u32 = 2u32.pow(16); | |||
pub const MAX_ASSETS: u32 = 64; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this const not already set somewhere ? Or it's an arbitrary value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was already set in XcmConfig::MaxAssetsIntoHolding
as ConstU64<64>
, I just refactor it to be primitives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's more of a const than a primitive though 🙂
Might be worth putting all consts into a separate module later on.
/bench shibuya-dev xcm_benchmarks_generic,xcm_benchmarks_fungible |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/7503066669. |
Benchmarks have been finished. |
/bench shibuya-dev xcm_benchmarks_generic,xcm_benchmarks_fungible |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/7511661871. |
Benchmarks have been finished. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I'd suggest to apply the 2nd comment, but the 1st one is more of a question so can be freely ignored.
/// Storage: ParachainInfo ParachainId (r:1 w:0) | ||
/// Proof: ParachainInfo ParachainId (max_values: Some(1), max_size: Some(4), added: 499, mode: MaxEncodedLen) | ||
/// Storage: PolkadotXcm SupportedVersion (r:1 w:0) | ||
/// Proof Skipped: PolkadotXcm SupportedVersion (max_values: None, max_size: None, mode: Measured) | ||
/// Storage: PolkadotXcm VersionDiscoveryQueue (r:1 w:1) | ||
/// Proof Skipped: PolkadotXcm VersionDiscoveryQueue (max_values: Some(1), max_size: None, mode: Measured) | ||
/// Storage: PolkadotXcm SafeXcmVersion (r:1 w:0) | ||
/// Proof Skipped: PolkadotXcm SafeXcmVersion (max_values: Some(1), max_size: None, mode: Measured) | ||
/// Storage: ParachainSystem HostConfiguration (r:1 w:0) | ||
/// Proof Skipped: ParachainSystem HostConfiguration (max_values: Some(1), max_size: None, mode: Measured) | ||
/// Storage: ParachainSystem PendingUpwardMessages (r:1 w:1) | ||
/// Proof Skipped: ParachainSystem PendingUpwardMessages (max_values: Some(1), max_size: None, mode: Measured) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this part a bit weird - shouldn't these be covered already by the XCM-related hooks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it weird too, but I checked in polkadot & system parachains xcm weights and they also have them - https://github.com/polkadot-fellows/runtimes/blob/187781f7606960d1a61d74a5c2c12d78dfe98bf4/system-parachains/asset-hubs/asset-hub-kusama/src/weights/xcm/pallet_xcm_benchmarks_fungible.rs#L75-L89
} | ||
} | ||
|
||
// For backwards compatibility and tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this needed given it's Shibuya-specific benchmark?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I'll remove them
Minimum allowed line rate is |
Supersedes - #1012
Pull Request Summary
This PR adds the XCM Benchmarks (for both generic and fungible instructions). This will replace the fixed unit cost we charge currently.
XCM Benchmarks
pallet-xcm-benchmarks
pallet which is separated intofungibles
(instr that deals with asset transfer, etc) andgeneric
.astar-xcm-benchmarks
is introduced which is a wrapper overpallet-xcm-benchmarks
with some benchmarks modified.WrappedBenchmark
struct is used to merge benchmarks.astar-xcm-benchmarks
structureNotes
pallet-assets
as assets since they involve additional DB read inXcAssetConfig
for converting location to asset-id. Therefore they will be more expensive then native asset (pallet_balances
)reserve_asset_deposited
benchmarks was not available till v1.x.x release therefore is manually copy-pasted for now.TODO
Check list