RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
Chen Liang
liach at openjdk.org
Tue Jun 27 10:26:17 UTC 2023
On Mon, 26 Jun 2023 09:57:31 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:
>
> use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1
For your info, the reviews required are approving GitHub reviews.
This patch looks great in shape; currently, I think the startup impact of ByteArray. If `UUID.toString` is used in early startup, this patch will increase the startup time for VarHandle initialization. #14636 replaces VarHandle with direct unsafe usage, which significantly reduces startup cost.
A search online says that `-Xlog:class+init=info:file=trace.log` can be added to VM options to print class initialization order. I think we might use it to check the startup impact by seeing if certain classes are loaded earlier now. Disclaimer: I personally haven't tried this; please correct me immediately if there is a better way to measure the startup impact.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609221851
More information about the core-libs-dev
mailing list