Skip to content
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

fix: remove extra compress call during pubkey::deserialize #56

Merged
merged 1 commit into from
Sep 6, 2021

Conversation

stringhandler
Copy link
Contributor

During deserialization, the compress and decompress method is called, when only one of them needs to be.

This should halve the time during from_bytes()

image

delta1
delta1 previously approved these changes Sep 3, 2021
Copy link
Contributor

@delta1 delta1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM untested

Copy link
Contributor

@CjS77 CjS77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice optimisation. One nit.

@@ -219,6 +219,13 @@ impl RistrettoPublicKey {
compressed: pk.compress(),
}
}

pub(crate) fn new_from_compressed(compressed: CompressedRistretto) -> Option<RistrettoPublicKey> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel like this should return a Result since our contract is that we always store a valid compressed/decompressed pair.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, agree

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

map(..).ok_or(E) will do it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There isn't an Error struct yet in the crate for this kind of error, and the method is only called privately from Deserialize which already exposes a ByteArrayError, so I restricted it further to super to reflect that it is private only and kept it as the Option that dalek exposes.

Copy link
Member

@sdbondi sdbondi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, this should improve performance - just one extra clone.

Just as a sanity check I ran the dalek benches, LGTM

RistrettoPoint decompression                                                                             
                        time:   [5.7858 us 5.8601 us 5.9463 us]
                        change: [-3.5477% -2.4195% -1.2709%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
  2 (2.00%) high mild
  1 (1.00%) high severe

RistrettoPoint compression                                                                             
                        time:   [4.0617 us 4.0944 us 4.1341 us]
                        change: [-52.136% -48.548% -45.005%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 10 outliers among 100 measurements (10.00%)
  9 (9.00%) high mild
  1 (1.00%) high severe

src/ristretto/ristretto_keys.rs Outdated Show resolved Hide resolved
Copy link
Member

@sdbondi sdbondi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@stringhandler stringhandler merged commit 8864b5a into tari-project:main Sep 6, 2021
stringhandler added a commit that referenced this pull request Sep 6, 2021
Bug Fixes
---

*   remove extra compress call during pubkey::deserialize (#56)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants