-
Notifications
You must be signed in to change notification settings - Fork 239
Open
Labels
Description
Aside from the thread-safety issue (which in Xstream is circumvented via the use of thread-locals), SimpleDateFormat causes the JDK to initialize all possible timezones, resulting in a heap overhead of about 3.5MB (measured on x86_64).
It would be better to use DateTimeFormatter and avoiding the use of the z pattern (which also triggers the initialization of the timezones).
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("ddMMyyyy HH:mm z");
formatter.parse("01012023 00:00 CEST");triggers the time-zone initialization, while
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("ddMMyyyy HH:mm VV");
formatter.parse("01012023 00:00 Europe/Paris");
does not.
The following table summarizes the heap impact:
| Strategy | LocalDateTime | LocalDate | ZoneInfo | ZoneOffset | Heap | Heap Delta (vs Baseline) |
|---|---|---|---|---|---|---|
| Baseline (no timezone calls) | 180 | 0 | 0 | 0 | 1845638 | 0 |
| Single Timezone [TimeZone.getTimeZone(id)] | 180 | 0 | 0 | 0 | 1845936 | 298 |
| All timezones with all variants [DateFormatSymbols.getZoneStrings()] | 57076 | 32212 | 602 | 1455 | 5605744 | 3760106 |
| All timezones with main variants [TimeZone.getAvailableIDs()+TimeZone.getTimeZone(id)+TimeZone.getName()] | 36678 | 21674 | 632 | 1155 | 4870584 | 3024946 |
| All timezones with no variants [TimeZone.getAvailableIDs()+TimeZone.getTimeZone(id)] | 180 | 0 | 632 | 0 | 2298216 | 452578 |
Reactions are currently unavailable