On Wed, 6 Jan 2021 00:41:29 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>> Are you sure you're not ending up paying more using a VarHandle and having >> to cast and using a var args call `(long) LONG_ARRAY_HANDLE.get(buf, ofs);` >> instead of creating a ByteBuffer once via >> `ByteBuffer.wrap(buffer).order(ByteOrder.nativeOrder()).asLongBuffer()`? > > 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`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1855
