On Mon, 26 Jun 2023 09:57:31 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: > > use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1 > I'm looking through > [[6b61a71](https://github.com/openjdk/jdk/commit/6b61a715caeeb586d5480a3a70f90bd1811d1335)], > update 24. > > Moving fastUUID out of Long is good. > > UUID::toString can use StandardCharsets. ISO_8859_1, no need to use > sun.nio.cs code here. > > The list of imports in java.util.UUID is a bit messy now, can you clean this > up. > > It's confusing to have java.util.HexDigits and jdk.internal.util.HexDigits. > It also creates an inconsistency with DecimalDigits and OctalDigits as the > latter encapsulate their arrays. I assume you've done this to allow sharing > of the 256 element array. I don't object to move the array to a supporting > class but it needs to be renamed and the class description replaced as it is > not a Digits implementation. Adding a private constructor would help make it > clear that it should not be instantiated. very good suggestion, i have modified it according to your suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609310739
