You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wrong about what was making non-ISO calendars so slow. I
thought the problem was `formatToParts()`, but it turns out that the
`DateTimeFormat` constructor is really slow and also allocates
ridiculous amounts of RAM. See more details here:
https://bugs.chromium.org/p/v8/issues/detail?id=6528@littledan in https://bugs.chromium.org/p/v8/issues/detail?id=6528#c4
recommended to cache DateTimeFormat instances, so that's what this
commit does.
The result is a 6x speedup in non-ISO calendar tests.
Before: 6398.83ms
After: 1062.26ms
A similar speedup is likely for `ES.GetCanonicalTimeZoneIdentifier`.
Caching time zone canonicalization (in a separate PR) should have
a big positive impact on ZonedDateTIme and TimeZone perf.
Many thanks to @fer22f for uncovering this optimization in
js-temporal/temporal-polyfill#7.
0 commit comments