-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification on PartitionDateTimePattern: Constructing NumberFormat instances #563
Comments
Good question. I don't see why the NumberFormat objects need to be created in the format function; it seems like they should be created in the constructor. Note that the spec only illustrates intended observable behavior; implementations can make optimizations as long as the observed behavior is the same. So, there's nothing right now preventing an implementation from caching the NumberFormat objects. |
I think moving |
I'm not sure if this issue describes the same underlying problem, but when I was building a proof-of-concept implementation of non-ISO calendars for Temporal, I was surprised at how slow it was to format calendar-localized dates. I'd assumed that this was inherent inefficiency in the ICU implementation, but if there's another, easier-to-resolve cause, that would be great news! |
@sffc proposal or PR? |
This is editorial, so a PR would suffice. |
ICU-based implementations only implement the first two steps of
They were probably created there because they aren't used anywhere else, so it could be argued it's cleaner to keep these as locals within |
Ref: https://402.ecma-international.org/7.0/#sec-partitiondatetimepattern
The steps in
PartitionDateTimePattern
include constructing two separateNumberFormat
instances. (step 6 and 10)This operation is called when formatting every single date and it can be really slow.
Caching the two
NumberFormat
instances by locale instead of constructing them every time can increase the performance of formatting dates anywhere from 20x to 100x. This is especially important for lower end devices, or for jitless runtimes.Is there any recommendation on how to handle this? Is caching appropriate here?
How do other implementations handle this?
The text was updated successfully, but these errors were encountered: