I don't know it's same problem or not. When we replace 'moment-timezone' with 'dayjs.tz', it's very slow.

Here is performance

All point to proto.tz

Hi, it seems this issue does not have any visibility.
We are observing the same damming performance on our end, and it is starting to become an issue.

We might move away from the timezone plugin for some of our hot functions, but I'd be happy to contribute back to a package that we use so extensively.

It seems like the timezone plugin is the only place in the codebase where there's still usage of toLocaleString().
I'd be keen on submitting a PR that would implement the solution presented by @janousek , but I'm afraid I am unsure of how dayjs manages caching.
If anyone can point me to some file or relevant function, I'd be happy to give it a try.

This code seems to have landed in a different form on 1.11.5? https://github.com/iamkun/dayjs/blob/dev/src/plugin/timezone/index.js#L12

Now, we continued to have issues even with that version because
const target = date.toLocaleString('en-US', { timeZone: timezone })

ends up initializing a new version of Intl.DateTimeFormat each time, per MDN docs

We changed that with the following for better perf results:
const target = getDateTimeFormat(timezone).format(date);

@nuria how did you expose getDateTimeFormat since it isn't exported, was it just forked or copied?