-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
False
-
None
-
False
-
-
Invoking `Date.toString()` causes initialization and caching of all timezones, resulting in a ~3MB heap overhead on x86_64. The following table summarizes the cost of triggering the caching of all timezones, including the number of instances of some related types and the amount of extra heap required.
| LocalDateTime | LocalDate | ZoneInfo | ZoneOffset | Heap delta | |
|---|---|---|---|---|---|
| Baseline (no TZ calls) | 180 | 0 | 0 | ||
| Single timezone | 180 | 0 | 0 | 0 | 298 |
| DateFormatSymbols.getZoneStrings() | 57076 | 32212 | 602 | 1455 | 3760106 |
| TimeZone.getAvailableIds() + TimeZone.getName() | 36678 | 21674 | 632 | 1155 | 3024946 |
| TimeZone.getAvalableIDs() | 180 | 0 | 632 | 0 | 452578 |
By using `Instant.toString()` instead we avoid the TZ caching.
The timestamp will be formatted differently:
Instant.toString() -> 2023-10-12T10:20:35.737069939Z
Date.toString() -> Thu Oct 12 12:20:35 CEST 2023
which is a potentially backwards incompatible.
