Should PlainYearMonth be using `month` instead of `monthCode` when reading from instances?

[justingrant]

While reviewing #2003, I noticed that PlainYearMonth is using the monthCode field instead of the month field whenever it needs to read properties of PlainYearMonth instances (e.g. in add, subtract, with, etc.).

Given that monthCode requires string creation and string parsing but month only requires numbers, will it improve performance to use month instead? For built-in calendars, I suspect that implementers can optimize the strings away but for user calendars it's an observable operation so the string usage is unavoidable. I suspect it'd also simplify implementations if the built-in path and the user-calendar path could use the same data types.

Here's the relevant pattern from the spec:

        1. Let _fieldNames_ be ? CalendarFields(_calendar_, « *"monthCode"*, *"year"* »).
        1. Let _fields_ be ? PrepareTemporalFields(_yearMonth_, _fieldNames_, «»).

@FrankYFTang do you have an opinion?

[ptomato]

I think we shouldn't preemptively guess what might need to be optimized — we can just let this feedback come from implementations.

[ptomato]

@justingrant Frank asks which sites you were talking about specifically?

[justingrant]

add, subtract, since, until. I don't think this pattern is used elsewhere, but someone who's not on a plane with crappy wifi right now should check. :-)

[FrankYFTang]

How about the following?
https://tc39.es/proposal-temporal/#sec-temporal.plainyearmonth.prototype.toplaindate
https://tc39.es/proposal-temporal/#sec-temporal.plaindate.prototype.toplainyearmonth
https://tc39.es/proposal-temporal/#sec-temporal.plaindatetime.prototype.toplainyearmonth
https://tc39.es/proposal-temporal/#sec-temporal.zoneddatetime.prototype.toplainyearmonth

I am not quite sure I understand what you are proposing here because it seems all of these are observable. Isn't that true that "month" maybe ambigous in non-iso8601 calendar? @sffc

[justingrant]

month and year together are never ambiguous, and with PlainYearMonth you always know the year. The ambiguity comes with PlainMonthDay because the same month can be a different monthCode depending on the year.

My connection isn't good enough to load the links above, but @ptomato will know whether the same issue applies there too.

What I'm wondering is whether we should change the spec (it would be a normative change) to use month instead of monthCode in cases where the year is known, but only if that change has a benefit for implementers (e.g. using number month instead of string monthCode avoids memory allocations).

[ptomato]

My guess is that it would not have much of a benefit for implementors. If the calendar is built-in and unmodified, Calendar.prototype is unmodified, and the monthCode and year getters are not overridden or replaced (which is the vast majority of cases) then none of the potentially observable accesses can actually be observed, and the whole thing can be optimized away, and replaced with internal slot accesses. It's for tricks like this why we are doing stuff like #1808.

For the rare cases of custom calendars I think it could go either way, depending on the calendar, whether it'd be more efficient to receive the numeric month or the month code.

[justingrant]

OK, sounds not worth the change unless Frank disagrees.

[ptomato]

No follow up, so I'll close this. Feel free to reopen if there is an optimization concern.