On Thu, 29 Jun 2023 08:46:32 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: > > revert HexDigits.DIGITS private > HexDigits.DIGITS > I've read through > [26f3a6a](https://github.com/openjdk/jdk/commit/26f3a6a5317718235bc3506f0a3e851001f43404) > (iteration 29) and it mostly looks okay. > > It's good to see the UUID code removed from Long. > > It's unfortunate that UUID is directly accessing HexDigits.DIGITS but at > least its in the same package and the array is accessed more widely. If there > were frozen arrays then this would be better. Have you measured using an > accessor method to access the array elements rather than accessing the array > directly? > > Somewhat subjective but I find the new comment in Digits a bit confusing, > particularly "In the byte[] encoded in LATIN1" as a byte[] is just bytes and > I think you want to say a String encoding as LATIN1 in a byte[]. Maybe drop > this and the reference to jdk.internal.util.ByteArray. Good suggestion, it has been modified and submitted. now UUID#toString codeSize is 203, less than default FreqInlineSize 325, It can be inline, and the performance is better than the previous version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1612648221
