On Fri, 12 Dec 2025 22:24:07 GMT, Justin Lu <[email protected]> wrote:
>> This PR addresses a performance degradation when constructing a new >> MessageFormat that contains a subformat with a pattern that is not a >> predefined style. This is due to internal logic which catches an IAE >> specifically for subformat patterns. Perf tests for choice and number are >> not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ± 6.766 >> ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ± 11.413 >> ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error >> Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ± 55.012 >> ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ± 47.370 >> ops/ms > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > pull values() into a var Looks good. Glad we fixed the performance regression, and kudos to the bug submitter src/java.base/share/classes/java/text/MessageFormat.java line 1993: > 1991: > 1992: // Returns a FormatStyle corresponding to the input text > 1993: // DEFAULT is the empty String, the pre-defined styles are 1-1 > with their The comment could mention that pre-defined ones are lower case ones of the enum names, but compared with the input styles ignoring cases for historical reasons ------------- PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3573794462 PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2615745186
