-
Notifications
You must be signed in to change notification settings - Fork 741
Memoise computation of empty hash #2538
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
Conversation
Benchmark resultsInstruction countsSignificant differencesClick to expand
Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Additional informationCheckout details:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2538 +/- ##
=======================================
Coverage 95.30% 95.31%
=======================================
Files 97 97
Lines 21520 21565 +45
=======================================
+ Hits 20510 20555 +45
Misses 1010 1010 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be overkill to write a test to check each supported algorithm's hash_for_empty_input()
either returns None
, or bytes matching those produced from calling hp.start().finish()
directly?
I spot-checked the values here and the chance of regression seems pretty low, but simultaneously it seems like the test would be easy to write. No strong pref either way.
c694219
to
55c3125
Compare
For a small, common set of
HashAlgorithm
s, we now just inherently know theirhash::Output
for the empty input. This value is used in the TLS1.3 key schedule.