AdapterDayjs - excessive invocations of dayjs.locale() method

[paal-havnevik-jobbkretser]

Steps to reproduce

Steps:

1. clone the mui-x repo (this repo)
2. run pnpm i
3. replace file /packages/x-date-pickers/node_modules/dayjs/dayjs.min.js with the attached file dayjs.min.js.txt (remove the .txt extension). The attached file extends the dayjs parseLocale()method with aconsole.log('dayjs.parseLocale invoked');` call.
4. run pnpm start
5. browse to http://localhost:3001/x/react-date-pickers/date-picker/ with Chrome Dev tools open
6. observe ~20.000 console log entries: dayjs.parseLocale invoked

Modified dayjs.min.js.txt:

dayjs.min.js.txt

Current behavior

The documentation page (http://localhost:3001/x/react-date-pickers/date-picker/) will invoke the dayjs.locale() (internally named parseLocale in dayjs) method some 20.000 times upon initial page load.

Selecting dates in the picker increases the amount of calls quickly.

Expected behavior

Fewer calls to dayjs.locale().

Context

I stumbled upon this when debugging why the given i18n locale from ThemeProvider was ignored in only parts of the date picker "Mobile" view: the date and day name in the picker header was not translated, but the months list and action buttons were.

Your environment

npx @mui/envinfo

System:
OS: Windows 10 10.0.19045
Binaries:
Node: 22.16.0 - C:\Program Files\nodejs\node.EXE
npm: 10.9.2 - C:\Program Files\nodejs\npm.CMD
pnpm: 10.12.1 - ~\AppData\Roaming\npm\pnpm.CMD
Browsers:
Chrome: 137.0.7151.104
Edge: Chromium (137.0.3296.83)
npmPackages:
@emotion/react: catalog: => 11.14.0
@emotion/styled: catalog: => 11.14.0
@mui/icons-material: catalog: => 7.1.1
@mui/internal-babel-plugin-display-name: ^1.0.1 => 1.0.1
@mui/internal-babel-plugin-resolve-imports: ^2.0.4 => 2.0.4
@mui/internal-bundle-size-checker: ^1.0.5 => 1.0.5
@mui/internal-markdown: ^2.0.6 => 2.0.6
@mui/internal-test-utils: catalog: => 2.0.9
@mui/material: catalog: => 7.1.1
@mui/monorepo: github:mui/material-ui#29efc5bbdfe28d944c754d5be4a1c2761ec34f7a => 7.1.1
@mui/utils: catalog: => 7.1.1
@types/react: catalog: => 19.0.12
react: catalog: => 19.0.0
react-dom: catalog: => 19.0.0
typescript: ^5.8.3 => 5.8.3

Search keywords: adapterdayjs dayjs

[flaviendelangle]

Interesting, it seems that when calling someDayjsDate.locale(someLocale), dayjs clones the object and runs all the logic in parseLocale even if the someLocale is already the locale of someDayjsDate.

I'll try making our code smarter to avoid this 👍

[flaviendelangle]

I removed a lot of calls to someDayjsDate.locale in our code and it reduced the amount of calls from ~18 000 to ... ~17 000 😢

I would need to investigate more, but for me the issue is that any time we create a date (and calling someDayjsDate.add(1, 'month') creates a date for example), it calls parseLocale internally...

Did you notice performance issue with this amount of calls to parseLocale?
We could investigate to reduce the amount of dates created, but we need to create lots of dates (to create the UI, to validate the value etc...). Maybe we can find some hotspot where we create way to many dates, but I don't expect massive breakthrough.

[paal-havnevik-jobbkretser]

I removed a lot of calls to someDayjsDate.locale in our code and it reduced the amount of calls from ~18 000 to ... ~17 000 😢

I would need to investigate more, but for me the issue is that any time we create a date (and calling someDayjsDate.add(1, 'month') creates a date for example), it calls parseLocale internally...

Did you notice performance issue with this amount of calls to parseLocale? We could investigate to reduce the amount of dates created, but we need to create lots of dates (to create the UI, to validate the value etc...). Maybe we can find some hotspot where we create way to many dates, but I don't expect massive breakthrough.

That was perhaps an underwhelming improvement :-)

The main issue I faced was trying to change the language in i18next without reloading the page.

In the i18n.on('languageChanged', { lng } => ....) handler I invoked the dayjs.locale() method to keep the new locale in sync between i18next and dayjs.

Sometimes the call to dayjs.locale() had no effect, the method run but the dayjs language was not changed. Asserting the dayjs locale after changing it failed from time to time (ie invoking console.assert(dayjs.locale() === newDayJsLocale .... after calling dayjs.locale(newDayJsLocale)).

Setting the current dayjs.locale() in the promise returned after initialising i18next also didn't work reliably until I put it in a setTimeout - which lead me down this rabbit hole. I am not sure if the massive amounts of invocations is to blame for that issue.

I was uncertain if the issue was in mui-x's usage of dayjs or internal to dayjs itself.

[flaviendelangle]

Make sense.
I'll try to benchmark a bit more our date creation to see if we have some easy wins to do. But yeah a lot of the problem seems to come from the day.js side here.