-
Notifications
You must be signed in to change notification settings - Fork 105
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
Fresh weights for stable2409 + fixes #522
Fresh weights for stable2409 + fixes #522
Conversation
…arachains::on_demand` according to the paritytech/polkadot-sdk#4706
Fresh weights for `pallet_beefy_mmr`
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
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.
That benchmark was added with this polkadot-sdk's PR.
So, in comparison to the real generated value:
I would say that it seems appropriate |
I added fresh weights for coretimes: a07036c, new diff: CoretimeKusama
CoretimePolkadot
|
@ordian can you please double check this is correct ? |
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.
enact_candidate looks excessive in the summary, but base weight still looks reasonable. So probably fine. @ordian
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.
Previously, the weight of enact_candidate
was included in the weight of availability bitfields, but this was a bug, because the number of bitfields depends on number of validators, whereas number of enacted candidates depends on the number of cores. This was later (accidentally) fixed, but the enact_candidate
weight was unaccounted for. paritytech/polkadot-sdk#5270 was supposed to fix that.
The base weight of enact_candidate
still looks excessive and it was fixed in paritytech/polkadot-sdk#5526, but looks like it didn't make into the same release.
That being said, even with 1.5ms of enactment weight per candidate, this shouldn't be a blocker to scale to 200 parachains weight-wise. So I'm fine with having these excessive weights for now.
/merge |
Enabled Available commands
For more information see the documentation |
@ordian The next patch, stable2409-4, is planned for this week. I have backported your fix here: paritytech/polkadot-sdk#7145. Once it is released, I will re-run the benchmarks for this within another PR. |
@acatangiu I'll do that. However, I have no reference machine. But I guess the difference is non-critical |
b677b84
into
polkadot-fellows:main
This PR includes the following changes:
runtime_parachains::assigner_on_demand
toruntime_parachains::on_demand
as per PR #4706.See commit: 6d31b3d8070580e74ec1d9b9fa6f128eb122891d.
pallet-beefy-mmr
to the benchmarking list.See commit: 4bede4a8828d6ce4b0c0a38f63a72ead6989235b.
TODO
pallet-beefy-mmr
, as there were previously some non-generated weightsRelay chains
Kusama
Polkadot
System parachains
AssetHubKusama
AssetHubPolkadot
BridgeHubKusama
subweight compare commits --path-pattern "./system-parachains/bridge-hubs/bridge-hub-kusama//weights//*.rs" --format markdown --no-color --change added changed --method asymptotic --ignore-errors --strip-path-prefix="system-parachains/bridge-hubs/bridge-hub-kusama/src/weights" remotes/polkadot-fellows/main origin/bko-weights
BridgeHubPolkadot
CollectivesPolkadot
CoretimeKusama
CoretimePolkadot
PeopleKusama
PeoplePolkadot
GluttonKusama
EncointerKusama