Cache Intl.* constructors

[victorandree]

Is your feature request related to a problem? Please describe.

It seems like on every call to format.number, or similar, there's a call to the corresponding Intl.NumberFormat constructor. This is potentially expensive: A microbenchmark that I constructed suggests a 97% performance decrease (see https://jsbench.me/09lf9t531d/1). An older blog post suggests a more dramatic performance difference: https://blog.david-reess.de/posts/hBEx9w-on-number-formatting-and-performance.

As someone coming from FormatJS, whose documentation emphasizes the use of createIntlCache (see https://formatjs.io/docs/intl), I was a bit surprised to see that this optimization is not present in next-intl.

Admittedly, on modern hardware like my M2 MacBook Pro, the absolute performance seems OK for both cases, even if there's a 49x relative difference.

Describe the solution you'd like

I'd suggest caching the construction of Intl.*Format objects between calls, perhaps by the createFormatter function, or in the context.

Admittedly, this would add complexity and size to the library, for the caching and memoization functionality, and might not be considered worth it.

Describe alternatives you've considered

Alternatively, if this is a known trade-off, I think it'd be good to mention in the documentation that it's been made. For example, in the FAQ section "How is this library different from using react-intl?".

[amannn]

Hi and thanks for the careful analysis!

I ran the performance test that's mentioned in David Reess' blog article and on my 2019 MBP I see that the formatting takes about 0.1ms, so it seems like creating formats have gotten faster (or David used a computer with less CPU power).

That said, if the bundle size is not affected, it would still be interesting to introduce caching.

I'm currently quite busy with the RSC integration and can therefore not look into this at the moment, but if you're affected by this and would be willing to contribute, I'd be happy to review a PR!

The formatting calls are located in this file: https://github.com/amannn/next-intl/blob/be9172099aad1e7057c828065dced5d2c0e0884d/packages/use-intl/src/core/createFormatter.tsx.

We should setup something like CodSpeed to monitor the runtime performance (example).

Note that we should apply caching both to the formats created in useTranslations as well as useFormatter.

[amannn]

Just benchmarked this again, and I think we should really cache the constructors:

• Intl.NumberFormat
• Intl.DateTimeFormat