paritytech / paritytech/parity-common
Performence issue + wrapping_{add,sub}
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 311
- Forks
- 245
- PR merge metrics
- No merged PRs in 30d
Description
Hello, first of all, i'm new with rust, so i could miss some concept...
i have a MerkleTree in rust, and i was using the ethnum library.
the library was missing the Serialize/Deserialize, and your library is more complete. so i decided to switched.
Just i was missing those function:
which i implemented that way:
pub fn wrapping_add(lhs: U256, rhs: U256) -> U256 {
match lhs.checked_add(rhs) {
None => {
if lhs > rhs {
lhs - (U256::MAX - rhs) - 1
} else {
rhs - (U256::MAX - lhs) - 1
}
}
Some(x) => x,
}
}
pub fn wrapping_sub(lhs: U256, rhs: U256) -> U256 {
match lhs.checked_sub(rhs) {
None => {
if lhs > rhs {
U256::MAX - (rhs - lhs) + 1
} else {
U256::MAX - (rhs - lhs) + 1
}
}
Some(x) => x,
}
}
Maybe it's because of those functions... (or something else ?) but my MerkleTree(16 floors) creation + insert 1 leaf went from ~6s to 19s...
Do you have any tips or advice to reduce this time ?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No project file or test is named. Start by reproducing the 16-floor MerkleTree insertion benchmark in Rust, then compare the wrapping_add and wrapping_sub paths with the existing checked operations and ethnum. Done means the slowdown is isolated and the needed wrapping behavior or performance guidance is captured with a reproducible result.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 18/100