JDK-8310502 : Optimization for j.l.Long.fastUUID() #14578
Conversation
|
👋 Welcome back wenshao! A progress list of the required criteria for merging this PR into |
|
wenshao
force-pushed
the
jdk_8310502_fast_uuid
branch
from
b8e7085 to
e0bcf6c
Compare
|
@wenshao Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information. |
got it |
|
fyi, the title of this PR need to match exactly the title of the bug JDK-8310502. |
wenshao
changed the title
i have made the changes. is it ok now? |
|
The Bots have removed the warning so the titles match. |
|
About @Glavo's VH suggestion: I think it is feasible, since the VH field is not initialized until the method is used, so there should be no startup issue. On a side note, JDK itself has a |
|
I've tested the benchmarks and the patch and baseline (with extra stable annotation) with a slightly varied version suitable for gradle run: package com.alibaba.openjdk;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Warmup;
import org.openjdk.jmh.infra.Blackhole;
import java.util.UUID;
import java.util.concurrent.TimeUnit;
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Warmup(iterations = 3, time = 10)
@Measurement(iterations = 6, time = 5)
@Fork(1)
public class UUIDUtilsBenchmark {
public static UUID uuid = UUID.randomUUID();
@Benchmark
public void jdk(Blackhole bh) {
bh.consume(uuid.toString());
}
@Benchmark
public void fast(Blackhole bh) {
bh.consume(UUIDUtils.fastUUID(uuid));
}
}The throughput varies a lot between iterations somehow; the patch and baseline with stable has no significant difference (i.e. within the error range, about 10%) |
|
/reviewers 2 |
|
@AlanBateman |
AlanBateman
left a comment
AlanBateman
left a comment
There was a problem hiding this comment.
I think you've got this to a good place with version 93e74b6. It might be helpful if the Digit.digts methods mentioned the endianness in the comment otherwise okay.
liach
left a comment
liach
left a comment
There was a problem hiding this comment.
I think ByteArray can be safely used here: UUID is not used by anything in java.base and shouldn't be initialized on VM startup.
|
|
@wenshao This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 130 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@AlanBateman) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
|
/integrate |
|
/integrate |
|
/sponsor |
|
Going to push as commit 20f7d05.
Your commit was automatically rebased without conflicts. |
openjdk
bot
removed
ready
|
@DamonFool @wenshao Pushed as commit 20f7d05. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
|
@DamonFool In the future, please wait at least 24 hours before sponsoring changes like this. There have been 33 revisions of this change, many of the people that have commented, potential reviewers are in many time zones and need to have time to see a chance to look at changes before they are integrated. |
| /** | ||
| * Combine two hex shorts into one int based on big endian | ||
| */ | ||
| static int digit(int b0, int b1) { |
There was a problem hiding this comment.
The method name digit is not very informative.
As it is package private it should be more descriptive and describe the parameters and result.
Perhaps packDigits or encodeAndPackHexDigits.
There was a problem hiding this comment.
can you create a new issue and i continue improving?
There was a problem hiding this comment.
can you create a new issue and i continue improving?
There was a problem hiding this comment.
@liach @RogerRiggs continue discussion in PR 14745
Okay, got it and will do so in the future. |
11 participants
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:
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578$ git checkout pull/14578Update a local copy of the PR:
$ git checkout pull/14578$ git pull https://git.openjdk.org/jdk.git pull/14578/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 14578View PR using the GUI difftool:
$ git pr show -t 14578Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14578.diff
Webrev
Link to Webrev Comment