-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b28
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8278727 | 19 | Eamonn McManus | P4 | Resolved | Fixed | b28 |
JDK-8294925 | 17.0.6 | Paul Hohensee | P4 | Resolved | Fixed | b01 |
This is Optional.toString() https://github.com/openjdk/jdk/blob/0699220830a457959b784b35af125b70f43fa3b0/src/java.base/share/classes/java/util/Optional.java#L454
/**
* Returns a non-empty string representation of this {@code Optional}
* suitable for debugging. The exact presentation format is unspecified and
* may vary between implementations and versions.
*
* @implSpec
* If a value is present the result must include its string representation
* in the result. Empty and present {@code Optional}s must be unambiguously
* differentiable.
*
* @return the string representation of this instance
*/
@Override
public String toString() {
return value != null
? String.format("Optional[%s]", value)
: "Optional.empty";
}
String.format is surprisingly expensive, and we are seeing Optional.toString() showing up as a measurable fraction of CPU time in Google's servers. This code could just as easily use string concatenation, which would certainly be cheaper.
Similar remarks apply to the other Optional* classes like OptionalInt, though they are used much less.
/**
* Returns a non-empty string representation of this {@code Optional}
* suitable for debugging. The exact presentation format is unspecified and
* may vary between implementations and versions.
*
* @implSpec
* If a value is present the result must include its string representation
* in the result. Empty and present {@code Optional}s must be unambiguously
* differentiable.
*
* @return the string representation of this instance
*/
@Override
public String toString() {
return value != null
? String.format("Optional[%s]", value)
: "Optional.empty";
}
String.format is surprisingly expensive, and we are seeing Optional.toString() showing up as a measurable fraction of CPU time in Google's servers. This code could just as easily use string concatenation, which would certainly be cheaper.
Similar remarks apply to the other Optional* classes like OptionalInt, though they are used much less.
- backported by
-
JDK-8278727 Optional.toString() is unnecessarily expensive
- Resolved
-
JDK-8294925 Optional.toString() is unnecessarily expensive
- Resolved
- duplicates
-
JDK-8275190 Improve performance for Optional, OptionalInt, OptionalDouble and OptionalLong toString function
- Closed
- links to
-
Commit openjdk/jdk17u-dev/ce949baa
-
Commit openjdk/jdk/fe2ae8e3
-
Review openjdk/jdk17u-dev/763
-
Review openjdk/jdk/6337
(2 links to)