On Thu, 1 Oct 2026 20:05:55 GMT, Naoto Sato <[email protected]> wrote:
>> Fixing performance regression caused by >> [JDK-8381379](https://bugs.openjdk.org/browse/JDK-8381379). Instead of >> having each explicit time zone as an entry in the resource bundle, the >> explicit DST offsets are encoded in one entry. This avoids repeated lookups >> for missing offsets and eliminates the need for a separate cache. Also >> `SimpleDateFormat` now issues a new internal `ZoneInfo` method that won't >> clone instances on each format call. Here is the benchmark result for the >> test case in the JBS entry (on my mac): >> >> Before: >> >> New York: 303.9 B/op, 191.7 ns/op >> Vancouver: 240.0 B/op, 216.8 ns/op >> >> After: >> >> New York: 32.0 B/op, 79.5 ns/op >> Vancouver: 32.0 B/op, 97.5 ns/op >> >> These results suggest that the performance has returned to approximately its >> pre-JDK- 8381379 level. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Fixed a typo Tested this locally against the current PR head and it looks good to me. Using the JBS reproducer, I got the following results on my machine: Before: America/New_York: 466.3 B/op, 630.7 ns/op America/Vancouver: 408.0 B/op, 428.1 ns/op After: America/New_York: 32.0 B/op, 241.0 ns/op America/Vancouver: 32.0 B/op, 280.3 ns/op Allocations dropped to 32 B/op for both zones, matching the pre-JDK-8381379 allocation level reported in the JBS issue. I also ran the timezone-related test groups under `java/util/TimeZone, java/time/test, sun/util/resources, sun/text/resources, and sun/util/calendar` along with CustomZoneTest from JDK-8392995. All passed: 150 passed, 3 skipped, with no failures or errors. Thank you for the quick turnaround @naotoj !! 🙌 ------------- PR Comment: https://git.openjdk.org/jdk/pull/33133#issuecomment-5940248394
