Closed MonstraG closed 2 days ago
Looked at isEnglish
a bit, and it seems that it's used to check whether to show a default built-in english locale or a proper Intl.
isEnglish
fails for en-GB
which is not considered english.Yeah, isEnglish
really means isUSEnglish
. We use it because it's much faster than using Intl, and many pre-built formats use it (e.g. parsing RFC2822 dates). The expensive part is checking if we can use it, and I think we can probably speed that up and/or make it less likely to be needed.
Hi team,
Is there a plan to improve this function? We've identified significant performance issues related to this function call, specifically with the line in Node.JS.
new Intl.DateTimeFormat(this.intl).resolvedOptions().locale.startsWith("en-us")
This part appears to consume a considerable amount of CPU, leading to noticeable performance degradation.
Any insights or plans for optimization would be greatly appreciated.
Thank you!
I'm profiling a calendar page which shows a bunch of events. I collect a profiling file and open it in https://www.speedscope.app, look at sandwich view, and see that![image](https://user-images.githubusercontent.com/17963791/235501441-b5aa04b5-4007-4893-a606-3b28950bbdfe.png)
isEnglish
is the 3th slowest function (by self time) (and supportsFastNumbers is 5th):I take a look at
isEnglish
: https://github.com/moment/luxon/blob/07023283e74321c2080de9bb73070a3ffd2a7acc/src/impl/locale.js#L479-L485As I'm working in Norwegian locale, I assume this returns false, but most importantly - creates
new Intl.DateTimeFormat
on every call.I have not tried this yet, but I believe we can win some time if we cache
Intl.DateTimeFormat
(or avoid doing this check).Same happens in
supportsFastNumbers
.