Remove unnecessary conversions to hex format #643
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR primarily focuses on performance improvement for the two digital signature algorithms supported by `dwn-sdk-js.
Context
In this Discord thread @shamilovtim noted significant delays while profiling web5-wallet performance.
During the troubleshooting process, a tangentially related issue was discovered that unnecessarily reduces the performance of
Ed25519
andsecp256k1
sign operations. While updatingdwn-sdk-js
to the v2.0 versions of@noble/ed5519
and@noble/secp256k1
in PR #396, unnecessary conversions to hex format were added in thesign()
method (but notverify()
).The result of this change is that
sign()
performance degrades rapidly as the data size of the content increases:With a 100MB data payload, the sign operation in⚠️ 40 times slower ⚠️ than it should be.
dwn-sdk-js
isIf we switch the time axis to log scale, you can see that the verify operations both in
dwn-sdk-js
and@noble/ed25519
track almost identically, since verify does not include the conversion to hex before verification.Changes
src/jose/algorithms/signing/ed25519.ts
src/utils/secp256k1.ts
After implementing these changes, the performance of the sign operation is nearly identical whether called from the
dwn-sdk-js
wrapper or directly to the@noble
lib and scales linearly as the payload size increases: