Conversation
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including You can disable this status message by setting the WalkthroughThis update comprehensively refreshes benchmarking weight files across all runtime pallets and modules using new Substrate Benchmark CLI results, reflecting increased execution times and parameterized scaling. It also upgrades workflow dependencies, increments crate versions, and updates runtime version constants. Several weight function signatures now explicitly utilize their input parameters for more precise weight calculations. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Extrinsic
participant WeightFunction
participant BenchmarkData
User->>Extrinsic: Submit extrinsic with parameters
Extrinsic->>WeightFunction: Call weight function with parameters
WeightFunction->>BenchmarkData: Use updated constants and scaling
WeightFunction-->>Extrinsic: Return calculated weight
Extrinsic-->>User: Process with new weight
Estimated code review effort5 (>120 minutes) Possibly related PRs
Suggested labels
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Chralt98
added
s:review-needed
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (10)
zrml/futarchy/fuzz/Cargo.toml (1)
23-24: Inherit version from the workspace instead of hard-codingBecause the crate is
publish = false, keeping the version in sync brings no semantic benefit and is easy to forget next bump. Let Cargo use the workspace version automatically:-version = "0.6.1" +version.workspace = truezrml/prediction-markets/fuzz/Cargo.toml (1)
20-21: Useversion.workspace = truefor easier future bumpsSame rationale as the futarchy fuzz crate—inherit the workspace version to remove manual upkeep:
-version = "0.6.1" +version.workspace = truezrml/neo-swaps/fuzz/Cargo.toml (1)
35-36: Avoid manual version driftConsider delegating the version to the workspace:
-version = "0.6.1" +version.workspace = truezrml/combinatorial-tokens/fuzz/Cargo.toml (1)
35-36: Optional: inherit version from workspaceReduces copy-paste errors on future releases:
-version = "0.6.1" +version.workspace = truezrml/futarchy/Cargo.toml (1)
65-66: Remember to propagate the 0.6.1 bump to release artefacts (changelog / tag).
version = "0.6.1"looks good, but please double-check the workspace‐level CHANGELOG and make sure the release tag will be created so downstream users can fetch the new crate from crates.io.zrml/swaps/Cargo.toml (1)
68-69: Ensure workspace root and CI publish script pick up 0.6.1.The crate version has been updated, but the workspace root
Cargo.toml(and any automated publish workflow) must reference the same version to avoid a publish failure.zrml/orderbook/Cargo.toml (1)
60-61: Version bump acknowledged – consider regenerating docs.rs badge.After releasing 0.6.1, refresh README badges or docs links that still point to 0.6.0 so users land on the correct documentation.
primitives/Cargo.toml (1)
43-44: Primitives crate version updated – scan for hard-coded semver strings.Occasionally tests or scripts embed the previous version string. A quick grep for
"0.6.0"(outside weight files) will prevent stray mismatches..github/workflows/coverage.yml (1)
41-41: Cache action updated, consider aligning other actionsGreat to see
Swatinem/rust-cache@v2. While touching this workflow, also bumpactions/checkout@v2(line 23) tov3for the latest performance & bug-fixes:- uses: actions/checkout@v2 + uses: actions/checkout@v3.github/workflows/benchmark.yml (1)
42-44: Upgrade toSwatinem/rust-cache@v2—confirm compatibility & pin a minor/patch version
v2of the action revamped cache-key computation and default cargo target-dir handling.
Please double-check that:
- The job still restores the expected cache layer (look for unexpected full builds).
- No
CARGO_TARGET_DIRoverrides conflict with the new default.- You pin to a concrete release (
v2.x.y) to avoid silent breaking changes in future minor bumps.Example:
-uses: Swatinem/rust-cache@v2 +uses: Swatinem/rust-cache@v2.7.0
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (72)
.github/workflows/benchmark.yml(1 hunks).github/workflows/coverage.yml(1 hunks).github/workflows/docker-hub-parachain.yml(1 hunks).github/workflows/integration-tests.yml(9 hunks).github/workflows/rust.yml(4 hunks)integration-tests/tests/rt-upgrade-zeitgeist-chopsticks/test-zeitgeist-chopsticks-runtime-upgrade.ts(1 hunks)macros/Cargo.toml(1 hunks)node/Cargo.toml(1 hunks)primitives/Cargo.toml(1 hunks)runtime/battery-station/Cargo.toml(1 hunks)runtime/battery-station/src/lib.rs(1 hunks)runtime/common/Cargo.toml(1 hunks)runtime/common/src/weights/cumulus_pallet_parachain_system.rs(2 hunks)runtime/common/src/weights/cumulus_pallet_xcmp_queue.rs(7 hunks)runtime/common/src/weights/frame_system.rs(7 hunks)runtime/common/src/weights/orml_currencies.rs(6 hunks)runtime/common/src/weights/orml_tokens.rs(6 hunks)runtime/common/src/weights/pallet_author_inherent.rs(2 hunks)runtime/common/src/weights/pallet_author_mapping.rs(6 hunks)runtime/common/src/weights/pallet_author_slot_filter.rs(2 hunks)runtime/common/src/weights/pallet_balances.rs(8 hunks)runtime/common/src/weights/pallet_bounties.rs(12 hunks)runtime/common/src/weights/pallet_collective.rs(9 hunks)runtime/common/src/weights/pallet_democracy.rs(26 hunks)runtime/common/src/weights/pallet_identity.rs(17 hunks)runtime/common/src/weights/pallet_membership.rs(8 hunks)runtime/common/src/weights/pallet_message_queue.rs(11 hunks)runtime/common/src/weights/pallet_multisig.rs(4 hunks)runtime/common/src/weights/pallet_parachain_staking.rs(31 hunks)runtime/common/src/weights/pallet_preimage.rs(13 hunks)runtime/common/src/weights/pallet_proxy.rs(6 hunks)runtime/common/src/weights/pallet_scheduler.rs(10 hunks)runtime/common/src/weights/pallet_timestamp.rs(2 hunks)runtime/common/src/weights/pallet_treasury.rs(8 hunks)runtime/common/src/weights/pallet_utility.rs(2 hunks)runtime/common/src/weights/pallet_vesting.rs(10 hunks)runtime/zeitgeist/Cargo.toml(1 hunks)runtime/zeitgeist/src/lib.rs(1 hunks)zrml/authorized/Cargo.toml(1 hunks)zrml/authorized/src/weights.rs(3 hunks)zrml/combinatorial-tokens/Cargo.toml(1 hunks)zrml/combinatorial-tokens/fuzz/Cargo.toml(1 hunks)zrml/combinatorial-tokens/src/weights.rs(9 hunks)zrml/court/Cargo.toml(1 hunks)zrml/court/src/weights.rs(19 hunks)zrml/futarchy/Cargo.toml(1 hunks)zrml/futarchy/fuzz/Cargo.toml(1 hunks)zrml/futarchy/src/weights.rs(4 hunks)zrml/global-disputes/Cargo.toml(1 hunks)zrml/global-disputes/src/weights.rs(9 hunks)zrml/hybrid-router/Cargo.toml(1 hunks)zrml/hybrid-router/src/weights.rs(3 hunks)zrml/market-commons/Cargo.toml(1 hunks)zrml/neo-swaps/Cargo.toml(1 hunks)zrml/neo-swaps/fuzz/Cargo.toml(1 hunks)zrml/neo-swaps/src/weights.rs(11 hunks)zrml/orderbook/Cargo.toml(1 hunks)zrml/orderbook/fuzz/Cargo.toml(1 hunks)zrml/orderbook/src/weights.rs(4 hunks)zrml/parimutuel/Cargo.toml(1 hunks)zrml/parimutuel/src/weights.rs(4 hunks)zrml/prediction-markets/Cargo.toml(1 hunks)zrml/prediction-markets/fuzz/Cargo.toml(1 hunks)zrml/prediction-markets/runtime-api/Cargo.toml(1 hunks)zrml/prediction-markets/src/weights.rs(36 hunks)zrml/styx/Cargo.toml(1 hunks)zrml/styx/src/weights.rs(3 hunks)zrml/swaps/Cargo.toml(1 hunks)zrml/swaps/fuzz/Cargo.toml(1 hunks)zrml/swaps/rpc/Cargo.toml(1 hunks)zrml/swaps/runtime-api/Cargo.toml(1 hunks)zrml/swaps/src/weights.rs(10 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
runtime/common/src/weights/pallet_collective.rs (1)
zrml/court/src/weights.rs (2)
vote(59-59)vote(175-185)
zrml/court/src/weights.rs (5)
zrml/court/src/lib.rs (18)
join_court(536-547)prepare_exit_court(623-647)vote(722-766)denounce_vote(789-854)reveal_vote(873-938)T(1379-1379)T(1481-1481)T(1840-1840)T(2462-2462)T(2481-2481)T(2500-2500)reassign_court_stakes(1051-1157)set_inflation(1172-1185)handle_inflation(1363-1471)select_participants(1908-1941)on_resolution(2360-2385)exchange(2387-2429)clear(2575-2593)runtime/common/src/weights/pallet_collective.rs (1)
vote(156-167)runtime/common/src/weights/pallet_parachain_staking.rs (1)
set_inflation(70-78)zrml/authorized/src/lib.rs (3)
on_resolution(265-278)exchange(280-294)clear(343-354)zrml/prediction-markets/src/lib.rs (1)
on_resolution(2678-2712)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Summary
🔇 Additional comments (95)
zrml/swaps/rpc/Cargo.toml (1)
14-15: LGTM – version bump looks correctThe RPC crate is publishable, so an explicit version bump is appropriate and aligns with the rest of the workspace.
zrml/styx/src/weights.rs (3)
21-26: Metadata bump looks sane.Benchmark CLI version, date, steps & host details updated only – no functional impact.
Nothing to action here.
65-73: Cross(): weight numbers updated – please double-check DB IO counts.
reads(2)/writes(1)were kept unchanged while the minimum exec time jumped ~50 %. If the extrinsic logic evolved in parallel with the re-benchmarking, verify that the number of state accesses is still accurate; an under-count would under-price the call.
76-82: set_burn_amount(): nothing to flag.Minor weight increase only; IO counts unchanged and still correct for a single storage write.
zrml/parimutuel/src/weights.rs (4)
21-26: Benchmark metadata refresh acknowledged.No concerns with version/host/steps changes themselves.
70-78:buy()weight +60 % — check block-weight ceilings.New base weight ≈ 119 M. Ensure the maximum weight of a filled block (including proof sizes) still fits within the configured
BlockWeights::get().max_blockfor the runtime; otherwise the extrinsic could become un-dispatchable.
87-95: Similar ceiling concern forclaim_rewards().Weight now ≈ 121 M. Validate against the same runtime limit as above.
104-112:claim_refunds()weight spike.New weight ≈ 112 M plus 6 kB proof size. Perform the same runtime-limit sanity check.
macros/Cargo.toml (1)
9-9: Version bump to 0.6.1 approved.Ensure the workspace resolver propagates this to crates that depend on
zeitgeist-macros; otherwise all good.zrml/orderbook/fuzz/Cargo.toml (1)
19-19: Fuzz crate version aligned with workspace – LGTM.zrml/styx/Cargo.toml (1)
40-40: Crate version bump consistent – no issues.runtime/zeitgeist/Cargo.toml (1)
440-441: Runtime crate bumped to 0.6.1 – confirmspec_version/transaction_versionmatch.The crate version now aligns with the runtime constants, but please verify
runtime/zeitgeist/src/lib.rsindeed setsspec_version = 61andtransaction_version = 34to keep on-chain upgrades smooth.zrml/court/Cargo.toml (2)
52-52: Version bump to 0.6.1 looks good
No functional or metadata issues spotted in this file.
52-52: All workspace crates are on version 0.6.1
No remainingversion = "0.6.0"entries were found across any Cargo.toml files.zrml/parimutuel/Cargo.toml (1)
49-49: Parimutuel crate version bump acknowledged
Change aligns with the workspace release train.zrml/swaps/runtime-api/Cargo.toml (1)
21-21: Runtime-API crate updated to 0.6.1 – LGTM
No further action required.zrml/authorized/Cargo.toml (1)
42-42: Authorized crate version bump verified
Consistent with the rest of the workspace.zrml/hybrid-router/Cargo.toml (1)
100-100: Hybrid-router crate now at 0.6.1 – looks correct
Nothing else to flag.zrml/global-disputes/Cargo.toml (1)
50-50: Workspace consistency verified
- The root
Cargo.toml’s[workspace.package]section does not declare aversion, so there’s nothing to bump.- No member
Cargo.tomlpinszrml-global-disputes = { version = "0.6.0", … }(all references useworkspace = true).Everything is in order for the 0.6.1 bump.
zrml/prediction-markets/runtime-api/Cargo.toml (1)
18-18: Version updated – verify API compatibilityThe runtime-API crate moves to 0.6.1. That’s fine, but any downstream crate using a
^0.6constraint will now resolve to 0.6.1 automatically. If you rely on semver-breaking behaviour, bump the dependency explicitly to avoid unexpected lockfile drift..github/workflows/docker-hub-parachain.yml (1)
11-11: Runner upgrade LGTMSwitching the Hadolint job to
ubuntu-22.04is safe and aligns with the currentubuntu-latestimage. No further action required.runtime/battery-station/Cargo.toml (1)
448-448: Crate version bumped – ensure runtime constants matchThe crate is now 0.6.1. Confirm that
runtime/battery-station/src/lib.rs’sRuntimeVersionblock already sets:spec_version: 61, transaction_version: 34,to keep the on-chain upgrade atomic.
node/Cargo.toml (1)
190-194: Version bump looks good
zeitgeist-nodeis now0.6.1. No other metadata touched—GTG.
Ensure downstream crates that depend on=0.6.0are updated, otherwise Cargo may pull two versions.zrml/neo-swaps/Cargo.toml (1)
108-113: Consistent crate version bump acknowledgedVersion aligned to
0.6.1, matching the workspace release. Nothing else changed.zrml/market-commons/Cargo.toml (1)
33-38: Version updated—no issuesSimple metadata update to
0.6.1. All good.runtime/common/Cargo.toml (1)
87-92: Runtime common crate bumped to 0.6.1Change is isolated to package version; dependencies & features untouched. Looks fine.
.github/workflows/integration-tests.yml (2)
15-15: LGTM! Ubuntu runner upgrade improves security and performance.Upgrading from Ubuntu 20.04 to 22.04 LTS across all jobs is a good practice for better security, performance, and longer support lifecycle.
Also applies to: 51-51, 108-108, 164-164, 219-219
75-75: LGTM! Rust cache action upgrade improves CI performance.Upgrading from
Swatinem/rust-cache@v1tov2provides better caching performance and reliability for Rust builds.Also applies to: 132-132, 188-188, 243-243
integration-tests/tests/rt-upgrade-zeitgeist-chopsticks/test-zeitgeist-chopsticks-runtime-upgrade.ts (1)
111-111: LGTM! Timeout increase accommodates runtime upgrade performance changes.Doubling the timeout from 60s to 120s for the XCM transfer test is appropriate given the runtime version upgrade and weight recalibrations that may increase execution times.
zrml/combinatorial-tokens/Cargo.toml (1)
70-70: LGTM! Version bump aligns with coordinated v0.6.1 release.The version update from 0.5.5 to 0.6.1 brings this crate in line with the broader version synchronization across the codebase as part of this release.
zrml/prediction-markets/Cargo.toml (1)
97-97: LGTM! Standard patch version increment for coordinated release.The version bump from 0.6.0 to 0.6.1 is consistent with the coordinated release that includes weight recalibrations and other improvements.
zrml/swaps/fuzz/Cargo.toml (1)
70-70: LGTM! Fuzz package version alignment improves consistency.Updating from 0.0.0 to 0.6.1 brings this fuzz testing package into alignment with the main project versioning, which is good practice for workspace consistency.
runtime/zeitgeist/src/lib.rs (1)
92-95: LGTM! Version increments are properly coordinated.The runtime version updates correctly increment both
spec_version(60→61) andtransaction_version(33→34), which aligns with the coordinated runtime upgrade described in the PR objectives.runtime/battery-station/src/lib.rs (1)
94-97: LGTM! Version consistency maintained across runtimes.The battery-station runtime version updates match the zeitgeist runtime exactly (spec_version: 60→61, transaction_version: 33→34), ensuring proper coordination between runtime variants.
.github/workflows/rust.yml (1)
34-34: LGTM! Consistent dependency upgrade across all jobs.The update from
Swatinem/rust-cache@v1to@v2is applied consistently across all workflow jobs (format, checks, test_standalone, test_parachain, fuzz), which improves caching performance and maintains workflow reliability.Also applies to: 67-67, 118-118, 144-144, 175-175
runtime/common/src/weights/pallet_author_inherent.rs (2)
21-24: LGTM! Benchmarking environment properly updated.The weight file correctly reflects the new benchmarking setup with Substrate CLI v48.0.0 and AMD EPYC 7713 processor, ensuring weights are based on current tooling and hardware.
73-74: Execution time increases are expected and consistent across weight updatesA spot-check of other updated weight files shows their minimum execution times vary with extrinsic complexity, and none exhibit an unexpected regression:
- pallet_author_inherent.rs: increased from ~12.94 µs to ~27.58 µs (complex inherent logic)
- cumulus_pallet_xcmp_queue.rs: updated measurements range from ~4.64 µs up to ~19.88 µs depending on queue operations
These changes align with the switch to AMD EPYC 7713 benchmarking hardware and the differing workloads of each extrinsic. No further adjustments required.
runtime/common/src/weights/pallet_bounties.rs (2)
21-24: LGTM! Consistent benchmarking environment with other weight files.The benchmarking metadata matches the systematic update across the runtime, using Substrate CLI v48.0.0 and AMD EPYC 7713 processor for consistent weight calculations.
70-74: LGTM! Comprehensive weight recalibration across all extrinsics.All bounty extrinsics show increased execution times consistent with the new benchmarking environment. The parameter-based scaling factors (for
dandbcomponents) have also been properly recalibrated, ensuring accurate weight estimation for variable-sized operations.Also applies to: 85-87, 96-98, 109-111, 122-124, 133-135, 148-150, 163-165, 178-180, 189-191, 205-209
runtime/common/src/weights/orml_tokens.rs (2)
21-25: LGTM: Benchmarking metadata updated correctly.The benchmarking environment has been properly updated to reflect the new CLI version 48.0.0, increased steps/repeats for better accuracy, and the AMD EPYC 7713 hardware platform.
62-120: Weight increases are consistent with improved benchmarking methodology.All weight functions show significant increases in execution times (roughly doubling or more), which is expected given:
- More thorough benchmarking with 50 steps and 20 repeats
- Different hardware platform (AMD EPYC 7713 vs previous Ryzen)
- Updated Substrate CLI version 48.0.0
The database operations and proof sizes remain unchanged, indicating the increases are purely from more accurate execution time measurements.
runtime/common/src/weights/pallet_author_slot_filter.rs (3)
21-25: LGTM: Benchmarking environment updated consistently.The metadata reflects the same systematic updates as other weight files in this PR - CLI version 48.0.0, improved benchmarking parameters, and AMD EPYC hardware.
32-32: Runtime path updated to production build.The runtime path has been updated from release to production build, which is consistent with the overall benchmarking improvements in this PR.
63-64: Weight increase is reasonable and consistent.The modest increase in execution time (7,960 ns vs previous ~7,790 ns) and base weight adjustment aligns with the more thorough benchmarking methodology used across all weight files in this PR.
runtime/common/src/weights/orml_currencies.rs (2)
21-25: LGTM: Consistent benchmarking environment updates.The benchmarking metadata matches the systematic updates across all weight files in this PR, ensuring consistency in the recalibration effort.
62-114: Weight increases align with systematic re-benchmarking.All currency-related weight functions show significant increases in execution times, consistent with:
- More rigorous benchmarking (50 steps, 20 repeats)
- AMD EPYC 7713 hardware platform
- Updated Substrate CLI version
The database read/write counts and proof sizes remain unchanged, confirming these are purely execution time recalibrations.
runtime/common/src/weights/cumulus_pallet_xcmp_queue.rs (2)
21-25: LGTM: Benchmarking environment consistently updated.The metadata reflects the same systematic improvements as other weight files, with date 2025-07-11 indicating this was part of the coordinated re-benchmarking effort.
63-161: Significant weight increases are justified by improved benchmarking.All XCMP queue operations show substantial weight increases, particularly the complex message processing functions (
on_idle_good_msgandon_idle_large_msg). These increases are consistent with:
- More thorough benchmarking methodology (50 steps, 20 repeats)
- AMD EPYC 7713 hardware platform
- Updated tooling and more conservative weight estimates
The database operations and proof sizes remain unchanged, confirming these are execution time recalibrations.
runtime/common/src/weights/cumulus_pallet_parachain_system.rs (2)
21-25: LGTM: Benchmarking environment updated consistently.The metadata matches the systematic updates across all weight files, ensuring coordinated recalibration of the entire runtime.
74-81: Significant weight increases reflect more accurate benchmarking.The substantial increases in both base weight (~1.79M to ~4.03M) and per-parameter multiplier (~234M to ~454M) are justified by:
- More thorough benchmarking with 50 steps and 20 repeats
- AMD EPYC 7713 hardware providing more realistic performance characteristics
- Decreased standard error indicating more precise measurements
This function handles critical parachain message processing, so accurate weight estimation is essential for network security and performance.
runtime/common/src/weights/pallet_author_mapping.rs (2)
21-25: LGTM: Systematic benchmarking environment updateThe metadata correctly reflects the updated Substrate Benchmark CLI version 48.0.0, new AMD EPYC 7713 CPU, and improved benchmarking parameters (50 steps, 20 repeats vs. previous 2 steps, 0 repeats).
67-68: Weight increases are reasonable for the new benchmarking environmentAll weight functions show increased execution times, which is expected given the different CPU architecture (AMD EPYC 7713 vs. previous AMD Ryzen 9 7950X3D) and more rigorous benchmarking parameters. The increases are consistent across all functions.
Also applies to: 80-81, 95-96, 110-111, 125-126
runtime/common/src/weights/pallet_timestamp.rs (2)
21-25: LGTM: Consistent benchmarking environment updateThe metadata updates match the pattern established across all weight files in this PR, reflecting the improved benchmarking setup.
63-64: Weight increases are consistent with new benchmarking environmentBoth
set()andon_finalize()functions show increased execution times appropriate for the AMD EPYC 7713 CPU and enhanced benchmarking parameters.Also applies to: 72-73
zrml/futarchy/src/weights.rs (3)
21-25: LGTM: Benchmarking environment updated consistentlyThe metadata reflects the same systematic updates seen across all weight files in this PR.
70-71: Weight increases are appropriate for the new benchmarking setupThe increased execution times for
submit_proposalandmaybe_schedule_proposalare consistent with the pattern observed across other pallets.Also applies to: 81-82
91-98: Excellent improvement: Parameternnow properly utilized in weight calculationThe
take_proposalsfunction now correctly scales weight based on the number of proposals (n) with a linear formula (base + coefficient * n) instead of using a fixed weight. This provides more accurate weight estimation that scales with the actual workload.zrml/authorized/src/weights.rs (3)
21-25: LGTM: Consistent benchmarking environment updateThe metadata updates follow the established pattern across all weight files in this PR.
75-82: Excellent improvement: Parametermnow properly utilizedThe
authorize_market_outcome_first_reportfunction now correctly scales weight based on the number of markets (m) with linear scaling, providing more accurate weight estimation. The measured values also properly reflect the parameter dependency.
94-95: Weight increases are consistent with new benchmarking environmentAll other weight functions show appropriate increases in execution times reflecting the AMD EPYC 7713 CPU and enhanced benchmarking parameters.
Also applies to: 103-104, 112-113, 121-122, 130-131, 137-138, 145-145, 153-154
runtime/common/src/weights/pallet_message_queue.rs (2)
21-25: LGTM: Benchmarking environment updated consistentlyThe metadata follows the same systematic pattern established across all weight files in this PR.
65-66: Weight increases reflect new benchmarking environment accuratelyAll weight functions show increased execution times consistent with the AMD EPYC 7713 CPU and enhanced benchmarking parameters. Note that some operations like
service_page_item(~387ms) andexecute_overweight_page_updated(~304ms) have high execution times, which accurately reflects the complexity of these message queue operations.Also applies to: 78-79, 89-90, 100-101, 111-112, 124-125, 135-136, 148-149, 161-162, 174-175
runtime/common/src/weights/pallet_treasury.rs (1)
94-107: Validatepupper bound to keep weight accurate
on_initialize_proposalsnow charges31 870 566per additional proposal under the assumptionp ≤ 99.
Please confirm the runtime enforces this limit (or otherwise clampsp), or bump the weight formula to cover the true maximum to avoid under-estimation.zrml/orderbook/src/weights.rs (1)
70-74: Regenerated weights look soundThe new constants align with the upgraded benchmark tooling; no functional issues spotted.
zrml/hybrid-router/src/weights.rs (2)
83-101: Ensurenandoare range-checked
buyassumesn ∈ [2,16]ando ≤ 10. Dispatchable code must reject larger values or the weight will be under-charged.
124-142: Same concern forsell
sellrelies on the same bounds (n ≤ 10,o ≤ 10). Please verify the runtime enforces these limits.runtime/common/src/weights/pallet_utility.rs (1)
58-66: Lean linear model LGTMMoving from giant constants to a per-call linear charge greatly improves accuracy. No further issues noticed.
runtime/common/src/weights/pallet_balances.rs (1)
134-148: Enforceuceiling forupgrade_accountsWeight is computed for
u ≤ 1000. Make sure the extrinsic rejects or clamps higher values, otherwise the chain can be under-charged.runtime/common/src/weights/frame_system.rs (2)
132-143: Good: Parameterpis now properly utilized in weight calculationsThe
kill_prefixfunction now correctly uses thepparameter in its weight formula, adding linear scaling for both computation and database operations. This is a significant improvement over the previous version wherepwas ignored.
94-102: Verify the significant weight increase for code update operationsThe minimum execution time for
set_codehas approximately doubled from the previous benchmarks. While this could be due to hardware differences and more comprehensive benchmarking, please verify that this aligns with expected performance on the target hardware.runtime/common/src/weights/pallet_multisig.rs (1)
58-66: LGTM! Parameter usage improvements enhance weight accuracyAll weight functions now properly utilize their input parameters, particularly
s(number of signatories), which was previously ignored. This ensures weight calculations accurately reflect the computational complexity that scales with the number of signatories.runtime/common/src/weights/pallet_vesting.rs (1)
201-213: Excellent: Linear scaling with lock count now properly implementedThe
not_unlocking_merge_schedules,unlocking_merge_schedules, andforce_remove_vesting_schedulefunctions now correctly incorporate thelparameter (number of locks) in their weight calculations. This ensures accurate weight estimation based on the actual computational complexity.zrml/combinatorial-tokens/src/weights.rs (1)
225-235: Confirm inclusion ofnin weight calculationsThe generated weight functions for
redeem_position_sans_parentandredeem_position_with_parentcurrently ignore thenparameter, but the underlying logic loops overnitems (as shown in benchmarking and the pallet implementation):• In zrml/combinatorial-tokens/src/weights.rs
fn redeem_position_sans_parent(_n: u32, m: u32) -> Weight { … }fn redeem_position_with_parent(_n: u32, m: u32) -> Weight { … }• The
redeem_positionextrinsic iterates over anindex_setof sizen + 1, so its cost should grow withn.Please verify whether the omission of an
.saturating_mul(n.into())term (or similar) is intentional. If not, regenerate the benchmarks or adjust the weight formulas to account for the linear dependency onn.runtime/common/src/weights/pallet_scheduler.rs (2)
96-107: Significant improvement: Realistic weight calculation for fetching tasksThe
service_task_fetchedfunction now has a reasonable linear weight formula instead of an extremely large fixed value. The weight now properly scales with the size parameters, and the proof mode correctly changed toMeasuredfor variable-size storage.
71-81: Good: Scheduler functions now properly account for agenda sizeAll scheduler weight functions now correctly incorporate the
sparameter (agenda size) in their calculations, ensuring accurate weight estimation based on the number of scheduled items.runtime/common/src/weights/pallet_collective.rs (3)
134-149: LGTM! Parameters are now properly utilized in weight calculations.The removal of underscore prefixes and the inclusion of all parameters (
b,m,p) in the weight formula improves the accuracy of weight estimations.
156-167: LGTM! Parametermis now properly utilized.The weight function correctly incorporates the linear scaling factor based on the number of members.
287-298: LGTM! Parameterpis now properly utilized.The weight calculation correctly scales with the number of proposals.
zrml/neo-swaps/src/weights.rs (1)
318-331: Weight generation intentionally ignores_mBenchmark regressions for
deploy_combinatorial_poolshowed no measurable dependency on them(fuel) parameter, so the autogenerated weight function correctly omits_m. No changes are needed.• Location:
zrml/neo-swaps/src/weights.rs, functiondeploy_combinatorial_pool(n, _m)runtime/common/src/weights/pallet_membership.rs (1)
66-199: LGTM! All weight functions properly utilize themparameter.The updates consistently incorporate the membership count parameter
minto weight calculations across all functions, improving the accuracy of weight estimations.zrml/swaps/src/weights.rs (1)
79-92: LGTM! Asset count parameter properly incorporated.The weight functions correctly scale with the number of assets involved in pool operations.
runtime/common/src/weights/pallet_democracy.rs (2)
257-269: LGTM! Referendum count parameter properly utilized.The weight calculations correctly scale with the number of referendums being processed.
283-295: LGTM! Launch period variant properly scales with referendum count.The weight function correctly accounts for the additional complexity when handling the launch period.
runtime/common/src/weights/pallet_preimage.rs (2)
66-76: LGTM! Parameter usage in weight calculations is now explicit.The function signature and weight calculation have been correctly updated to use the
sparameter explicitly, which improves clarity and accuracy of the weight estimations.
238-258: Incorrect assumption about base DB operations inensure_updatedThe storage‐access counts in
ensure_updatedcorrectly match the number of items read and written per element—there are no extra “base” reads or writes beyond those. Specifically:
- Doc comments list three storages with reads (
StatusFor,System::Account,Balances::Holds) and four storages with writes (addsPreimage::RequestStatusFor) per element.- The code uses
.reads(3 * n)
.writes(4 * n)
with no standalonereads(...)orwrites(...)outside then‐multiplied calls.- Thus there’s no off‐by‐one or unexpected extra DB operations; the counts align perfectly with the documented accesses.
Please disregard the previous request to verify additional base reads/writes—they do not exist.
Likely an incorrect or invalid review comment.
runtime/common/src/weights/pallet_proxy.rs (1)
60-69: Parameter usage improvements are consistent and correct.All weight functions in this file have been properly updated to use their parameters explicitly. The linear scaling with saturating additions and standard error annotations follow best practices for weight calculations.
zrml/global-disputes/src/weights.rs (2)
79-91: Good optimization in parameter usage for weight calculations.The function now correctly uses both
oandvparameters in its weight calculation, providing more accurate scaling based on the number of outcomes and votes.
208-221: Parameterois marked as unused in both functions.Both
purge_outcomesandrefund_vote_feeshave marked theoparameter as unused (_o). This suggests the benchmarking revealed that the number of outcomes doesn't significantly impact the weight for these operations. This is a valid optimization if confirmed by benchmarks.Also applies to: 228-241
zrml/court/src/weights.rs (2)
88-98: Excellent parameter utilization in weight calculations.The
join_courtfunction now properly scales weight based on the number of jurors (j), providing more accurate weight estimations for different jury pool sizes.
256-272: Complex weight calculation forappealfunction looks correct.The function properly accounts for multiple parameters (
j,a) in its weight calculation, with appropriate scaling for database operations. The large standard errors (58M fora) reflect the significant variability in this operation, which is expected for appeal operations.runtime/common/src/weights/pallet_identity.rs (1)
60-70: Consistent and correct parameter usage across all identity functions.All weight functions in the identity pallet have been properly updated to:
- Use parameters explicitly in weight calculations
- Scale database operations appropriately with parameters
- Include standard error annotations for precision
These changes align with the broader update pattern across all pallets and should provide more accurate weight estimations.
Also applies to: 74-84, 92-105, 113-124
runtime/common/src/weights/pallet_parachain_staking.rs (2)
19-44: Benchmarking update looks comprehensive and well-executed.The weight file has been regenerated with significant improvements:
- Updated to Substrate Benchmark CLI v48.0.0
- Increased benchmarking rigor (50 steps, 20 repeats vs previous 2 steps, 0 repeats)
- New hardware environment (AMD EPYC 7713 vs AMD Ryzen 9 7950X3D)
These changes should provide more accurate and reliable weight measurements.
166-177: Excellent improvement in weight calculation precision.The weight functions now properly utilize their input parameters in the weight calculations, replacing the previous practice of ignoring them with underscore prefixes. This provides more accurate scaling based on actual computational complexity, which is crucial for proper fee estimation and resource management.
The addition of standard error annotations also helps understand the statistical variance in the measurements.
Also applies to: 183-194, 216-229, 252-265, 271-282, 288-299, 305-316, 330-341, 366-377, 391-402, 419-430, 450-461, 467-478, 573-584, 599-609, 726-740, 764-781, 852-865
zrml/prediction-markets/src/weights.rs (2)
19-44: Consistent benchmarking update across the codebase.This file follows the same benchmarking update pattern:
- Substrate Benchmark CLI v48.0.0
- AMD EPYC 7713 processor with 50 steps and 20 repeats
- Proper parameter usage in weight calculations
The consistency across different pallets ensures uniform weight accuracy throughout the runtime.
314-324: Parameter usage accurately reflects computational complexity.Functions like
start_global_disputeandschedule_early_close_as_authoritycorrectly ignore thenparameter in their weight calculations, indicating that these operations don't scale with that particular input. This selective parameter usage provides more accurate fee estimation compared to the previous approach of ignoring all parameters.Also applies to: 603-613
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1444 +/- ##
==========================================
- Coverage 93.38% 93.32% -0.06%
==========================================
Files 181 181
Lines 34625 34769 +144
==========================================
+ Hits 32334 32448 +114
- Misses 2291 2321 +30
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
mergify
bot
added
s:in-progress
Chralt98
added
s:review-needed
mergify
bot
added
s:in-progress
Chralt98
added
s:review-needed
daniellereyes
requested review from
saboonikhil
and removed request for
saboonikhil
Chralt98
added
s:accepted
4 participants
What does it do?
It updates the spec_version for battery station and zeitgeist main-net to 61, the transaction version to 34. It updates the weights using the benchmarks. It updates the crate versions to v0.6.1.
What important points should reviewers know?
Is there something left for follow-up PRs?
What alternative implementations were considered?
Are there relevant PRs or issues?
References
Summary by CodeRabbit
New Features
Bug Fixes
Chores
Refactor