Performance problem with DateTimeFormat polyfill #2813
Replies: 5 comments 8 replies
-
Beta Was this translation helpful? Give feedback.
-
Been poking at this out of curiosity. It appears that there's a complex implementation here: formatjs/packages/ecma402-abstract/262.ts Lines 204 to 211 in 4324002 Simply using Before: Not sure why that logic is used instead of using the native
|
Beta Was this translation helpful? Give feedback.
-
It appears the above function is called with a parameter of
|
Beta Was this translation helpful? Give feedback.
-
Public repository with the patches mentioned above if a maintainer wants to take a look: Currently about 100% slower without the patches. I think it can be made much much faster with memoization or other improvements. Most of the time is spent creating the same type of locale. One example is that it calls If I make that function simply The original, non patched version only does 9k ops per second, so it's a 100% speed-up with only a few minor changes. |
Beta Was this translation helpful? Give feedback.
-
Using The bottom line is that performance isn't a priority for us tbh since i18n is complex enough to be implemented correctly. This in combination with the fact that you have to strictly follow the spec to prevent security issues like object pollution or cross- |
Beta Was this translation helpful? Give feedback.
-
Which package?
It appears that using the DateTimeFormat polyfill to format dates can be extremely slow, especially on lower end Android devices.
We measured a single DateTimeFormat to 20ms on a real device. This blocks the main thread resulting in major performance problems.
Originally reported in: facebook/hermes#23 (comment) and comments around it.
Describe the bug
Not really a bug, but perhaps performance could be improved.
To Reproduce
Run the above script with
node --cpu-prof test.js
to see a cpu trace.Codesandbox URL
https://codesandbox.io/s/determined-nash-j9wug?file=/src/index.js
Expected behavior
DateTimeFormat
polyfill should not be so slow.Screenshots
Screenshot of profile session when using nodejs (slow paths can be seen there as well):
Additional context
Takes around 0.2-0.5ms per format on an M1 CPU which has among the best single threaded performance in the world right now. Takes around 20ms on a mid level android CPU.
Beta Was this translation helpful? Give feedback.
All reactions