On Sun, 25 Jun 2023 12:20:17 GMT, 温绍锦 <d...@openjdk.org> wrote:
>> By optimizing the implementation of java.lang.Long#fastUUID, the performance >> of the java.util.UUID#toString method can be significantly improved. >> >> The following are the test results of JMH: >> >> Benchmark Mode Cnt Score Error Units >> UUIDUtilsBenchmark.new thrpt 5 92676.550 ± 292.213 ops/ms >> UUIDUtilsBenchmark.original thrpt 5 37040.165 ± 1023.532 ops/ms > > 温绍锦 has updated the pull request incrementally with one additional commit > since the last revision: > > add jdk.util.HexDigits, sharing cache array across multiple classes, > including : > java.lang.Long#fastUUID > java.util.HexDigits > java.lang.Long#toHexString(future) > java.lang.Integer#toHexString(future) > java.util.HexFormat(future) i agree that backport is not the goal, but in the two packages java.util and java.lang share a cache array, it is more appropriate to put it in jdk.util. > > > I don't think this is feasible, for this uses a new feature and hampers > > backport to jdk11. > > I don't think affecting backports in general should be a reason to discourage > new features from being used. > > [wenshao@4a3da4b](https://github.com/wenshao/jdk/commit/4a3da4b20fe0f7244c2c7bde3d9a0e2c8b91455a) > is great for me. > > Implementing some functions of UUID in `Long` is inherently illogical. Now > that we can implement it efficiently in the `UUID` class, there's no reason > why we shouldn't. this implementation is cleaner and is my favorite. the implementation of changing JavaLangAccess and Long for UUID.toString in the baseline is too intrusive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606156842 PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606161285
