Improve usage of hashing for trimmer friendliness #91185
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.
Currently, when we want one-shot hashes, we offer, in our public API,
HashType.HashData
. Often enough we expose other APIs that operate off ofHashAlgorithmName
which is a strongly-typed string. When we wanted to one-shot withHashAlgorithmName
were switching over the name, and calling the appropriate static method.This however is not trimmer friendly. Those APIs that accept a HashAlgorithmName were pulling in all of the hash types, even if
HashAlgorithmName.SHA256
(for example) is the only one used.Our actual one-shot implementations want string of the hash algorithm name. So we were doing something like this:
Now we are doing
We still need to do some switching to determine hash algorithm sizes, however we are not rooting any types. The only thing we are using are public constants off of the types, which the compiler will inline.
This also, as a small matter of performance, reduces some indirection as well.
Fixes #91181.