On Wed, 6 Jan 2021 02:29:58 GMT, David Schlosnagle <[email protected]> wrote:
>> Since much of the cost is now the creation of the MessageDigest itself, I >> added a microbenchmark to stat this overhead: >> >> Benchmark >> (digesterName) Mode Cnt Score Error Units >> GetMessageDigest.cloneInstance >> MD5 avgt 30 124.922 ± 5.412 ns/op >> GetMessageDigest.cloneInstance:·gc.alloc.rate.norm >> MD5 avgt 30 280.015 ± 0.001 B/op >> >> That means there's no added allocation overhead of calling >> `MessageDigest.getInstance(digesterName)` compared to cloning an existing >> instance - which means we get almost all of the benefits without resorting >> to tricks as caching and cloning an instance at call sites such as the one >> in `UUID::nameUUIDFromBytes`. The remaining 20ns/op difference should be >> negligible. > > Nice speedup for all `MessageDigest.getInstance` and `Provider.getService` > invocations and improves on removing the scalability bottlenecks of > `Provider.getService` beyond > [JDK-7092821](https://bugs.openjdk.java.net/browse/JDK-7092821) (and related > [JDK-8080273](https://bugs.openjdk.java.net/browse/JDK-8080273) & > [JDK-8172827](https://bugs.openjdk.java.net/browse/JDK-8172827)). This will > also allow removing some longstanding `MessageDigest#clone` workarounds such > as in Guava https://github.com/google/guava/issues/1197 . Thanks for looking into this. I will take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/1933
