RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
Daniel Fuchs
dfuchs at openjdk.org
Tue Jun 27 13:13:25 UTC 2023
On Tue, 27 Jun 2023 11:27:18 GMT, 温绍锦 <duke at 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:
>
> fix UUID.java import, rename jdk.util.HexDigits to jdk.util.Hex256 and make private constructor.
src/java.base/share/classes/jdk/internal/util/Hex256.java line 38:
> 36:
> 37: @Stable
> 38: public static final short[] DIGITS;
It's a bit smelly to have a public static field of type array.
Static analysers are likely to flag this.
It would be better to make the field private and have a public static method that returns DIGITS.clone() - then each class that needs it (and if I'm not mistaken there are only two) could encapsulate its own private copy.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243711721
More information about the core-libs-dev
mailing list