2

I was running some benchmark, and noticed that the estimated proof size was less than the measured size, despite MaxEncodedLen being used in this crate. The estimation of 0 is clearly wrong, but this is the one that gets used in Weight::from_parts. My first guess was that MaxEncodedLen was perhaps implemented incorrectly, but they're all auto-derived so I don't think that can be the case. I also tried inspecting the max_encoded_len() of of the key type, and it was non-zero. What can cause this behavior?

/// Storage: VaultRegistry MinimumCollateralVault (r:0 w:1)
/// Proof: VaultRegistry MinimumCollateralVault (max_values: None, max_size: Some(43), added: 2518, mode: MaxEncodedLen)
fn set_minimum_collateral() -> Weight {
    // Proof Size summary in bytes:
    //  Measured:  `711`
    //  Estimated: `0`
    // Minimum execution time: 9_105_000 picoseconds.
    Weight::from_parts(9_553_000, 0)
        .saturating_add(T::DbWeight::get().writes(1_u64))
}
1

1 Answer 1

2

Looking at the comments shows that MinimumCollateralVault was not read - therefore it should not be in the proof. The problem here is actually that the Measured is wrong. The estimated Proof size of zero is correct.

This was fixed in #13485. Please try to update your Substrate version.
In any case; thanks for letting us know, only like this can we improve! When you are sure that there is a bug, you can better open an issue in GitHub directly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.