Clarification on PartitionDateTimePattern: Constructing NumberFormat instances

[andreialecu]

Ref: https://402.ecma-international.org/7.0/#sec-partitiondatetimepattern

Perform ! CreateDataPropertyOrThrow(nfOptions, "useGrouping", false).
Let nf be ? Construct(%NumberFormat%, « locale, nfOptions »).
Let nf2Options be ObjectCreate(null).
Perform ! CreateDataPropertyOrThrow(nf2Options, "minimumIntegerDigits", 2).
Perform ! CreateDataPropertyOrThrow(nf2Options, "useGrouping", false).
Let nf2 be ? Construct(%NumberFormat%, « locale, nf2Options »).
Let tm be ToLocalTime(x, dateTimeFormat.[[Calendar]], dateTimeFormat.[[TimeZone]]).

The steps in PartitionDateTimePattern include constructing two separate NumberFormat 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?

[sffc]

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.

[longlho]

I think moving NumberFormat construct to the constructor would also solve the caching issue, since you can just cache DateTimeFormat constructor and that'd subsequently cache all its internal constructors like PluralRules as well.

[justingrant]

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!

[longlho]

@sffc proposal or PR?

[sffc]

This is editorial, so a PR would suffice.

[anba]

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!

ICU-based implementations only implement the first two steps of FormatDateTimePattern. Everything else is handled internally in ICU, that means the NumberFormat allocations in FormatDateTimePattern never actually happen. So this change makes zero difference in performance for JSC/V8/SM/Graal etc.

---

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.

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 FormatDateTimePattern. But the spec doesn't use this approach consistently, for example InitializeRelativeTimeFormat creates internal NumberFormat and PluralRules objects even though they're only used within PartitionRelativeTimePattern.

[sffc]

2024-03-28 TG2 notes: https://github.com/tc39/ecma402/blob/main/meetings/notes-2024-03-28.md#clarification-on-partitiondatetimepattern-constructing-numberformat-instances