Closed victorandree closed 2 months ago
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
.
Just benchmarked this again, and I think we should really cache the constructors:
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 correspondingIntl.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 innext-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 thecreateFormatter
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?".