It is faster.
Created attachment 250918 [details] patch
Comment on attachment 250918 [details] patch Seems like computeHash could just return the Digest.
https://trac.webkit.org/r182895
Comment on attachment 250918 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=250918&action=review > Source/WTF/ChangeLog:22 > + Remove the side effect where computeHash resets the state. No one relies on it. All I see is the comment change and the new CommonCrypto. I don’t see a code change that makes that change for the non-CommonCrypto version. Is the idea that now computeHash might reset the state and might not? I think this is slightly untidy right now. I don’t know what the rules are about what you can and can’t do after calling computeHash and what behavior you should expect.
> All I see is the comment change and the new CommonCrypto. I don’t see a code > change that makes that change for the non-CommonCrypto version. Is the idea > that now computeHash might reset the state and might not? I think this is > slightly untidy right now. I don’t know what the rules are about what you > can and can’t do after calling computeHash and what behavior you should > expect. It seemed unnecessary to actually change the behavior of the existing implemention. It just calls reset() which sets the state back to initial state. This is not expensive and some sort of state cleanup is needed to not have computation left in memory. On the other hand I didn't want to introduce extra CC_SHA1_Init call to match this unused behavior. CC_SHA1_Final cleans up the state just fine. The new behavior is that you create new SHA1 instance for each computation. This is how the clients seem to expect it to behave anyway and matches similar MD5 type.