RFR: 8259498: Reduce overhead of MD5 and SHA digests
redestad at openjdk.java.net
Fri Jan 8 22:41:06 UTC 2021
On Wed, 6 Jan 2021 01:27:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:
>> Hitting up `new MD5()` directly could be a great idea. I expect this would be just as fast as the cache+clone (if not faster), but I'm a bit worried we'd be short-circuiting the ability to install an alternative MD5 provider (which may or may not be a thing we must support..), but it's worth exploring.
>> Comparing performance of this against a `ByteBuffer` impl is on my TODO. The `VarHandle` gets heavily inlined and optimized here, though, with performance in my tests similar to the `Unsafe` use in `ByteArrayAccess`.
> I've identified a number of optimizations to the plumbing behind `MessageDigest.getDigest(..)` over in #1933 that removes 80-90% of the throughput overhead and all the allocation overhead compared to the `clone()` approach prototyped here. The remaining 20ns/op overhead might not be enough of a concern to do a point fix in `UUID::nameUUIDFromBytes`.
Removing the UUID clone cache and running the microbenchmark along with the changes in #1933:
Benchmark (size) Mode Cnt Score Error Units
UUIDBench.fromType3Bytes 20000 thrpt 12 2.182 ± 0.090 ops/us
UUIDBench.fromType3Bytes:·gc.alloc.rate 20000 thrpt 12 439.020 ± 18.241 MB/sec
UUIDBench.fromType3Bytes:·gc.alloc.rate.norm 20000 thrpt 12 264.022 ± 0.003 B/op
The goal now is if to simplify the digest code and compare alternatives.
More information about the core-libs-dev