On Wed, 6 Jan 2021 01:27:52 GMT, Claes Redestad <redes...@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. ------------- PR: https://git.openjdk.java.net/jdk/pull/1855
