Slow module initialization time on low-end devices

[gaearon]

Which package?

@formatjs/intl-pluralrules/polyfill

Describe the bug

While not a bug per se, merely importing @formatjs/intl-pluralrules/polyfill causes a one second stall on a low-end Android device in a React Native project. For context, this is ~1s out of ~3.5s of our startup time, i.e. this polyfill is almost a third of the entire app's initialization time (which uses many other libraries including RN core itself).

I'm not sure what's special about this polyfill in particular. Maybe it's hitting some bad case. From inspecting the code, one thing that jumps out to me is that it pulls in the entirety of @formatjs/ecma402-abstract because it targets CJS, so a bunch of code gets initialized just to get invariant, FormatNumericToString, and ToNumber. Maybe publishing an ESM version would avoid that.

To Reproduce

This is reproducible with the Bluesky app (fully open source) on Samsung Galaxy A12. If there is interest, I can give more detailed instructions, but it's essentially about installing it, running yarn, then yarn android to run it on an Android simulator (assuming you have one set up).

[gaearon]

It seems like the issue is that the best fit matcher is very inefficient. You can see this by running the polyfill code unconditionally in Chrome with 6x CPU throttling.

[longlho]

yeah best fit matching is non-trivial. The algorithm is in LDML here. At a high level it has to calculate the distance between the requested locale and the dataset, taken into account some special regional grouping & preference like Latin America, then take the shortest one. We've already put in some shortcuts wrt local distance calculation, but overall it's quite heavy. Getting this to match icu4j is pretty tricky. I can take another look, but no promises.

[gaearon]

Cool, thanks. Would it be possible to offer a version of the polyfill that does 'lookup' instead?

Also, in general, something feels pathological about, say, passing en and then spending so much initialization time doing something. Zooming out of the specific CPU work being done here — is there any way something could be precomputed here? How do I explain it to myself why this CPU work needs to happen during initialization? Or maybe, could any of this work be shifted towards when it's absolutely necessary?

[longlho]

yeah because the 1st thing it tries to do is detect whether this platform needs polyfilling, which checks for a specific Chrome bug. If you're running on a platform that you know definitely needs polyfilling, you can import /polyfill-force instead.

The lookup locale algorithm is pretty bad, as it basically just removes 1 subtag at a time when trying to match, which would yield false negative for things like traditional Chinese.

[gaearon]

If you're running on a platform that you know definitely needs polyfilling, you can import /polyfill-force instead.

Fantastic, this hasn't even occurred to me but it's exactly what I needed.

[gaearon]

It would be still be great to somehow get this fixed upstream because I bet it's affecting a lot of RN apps that use @formatjs transitively. Most developers aren't aware how to debug init time issues so it probably translates to second stalls across a lot of apps.

[gaearon]

Actually nvm, I guess developers do include the polyfill itself manually so this was probably our mistake. Would be good to call it out in docs maybe.

[gaearon]

Thanks a lot for holding my hand through this, the last insight let me cut off a few hundred more ms.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sregg]

We improved our app start time by 3x by just replacing all polyfill imports with their -force versions.
That's 2s instead of 7s on my Pixel 6 Pro.
Thanks @gaearon for the hint 🙏