Skip to content

[perf] isEnglish and supportsFastNumbers are slow - new Intl.DateTimeFormat #1428

@MonstraG

Description

@MonstraG

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 isEnglish is the 3th slowest function (by self time) (and supportsFastNumbers is 5th):
image

I take a look at isEnglish :

luxon/src/impl/locale.js

Lines 479 to 485 in 0702328

isEnglish() {
return (
this.locale === "en" ||
this.locale.toLowerCase() === "en-us" ||
new Intl.DateTimeFormat(this.intl).resolvedOptions().locale.startsWith("en-us")
);
}

As 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.

  • OS: Win 11
  • Browser: Chrome 112.0.5615.138
  • Luxon: 3.3.0

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions