perf: constant time JSTimers/_callTimer

[dagohan]

Summary:

JSTimers.js manages the callbacks of setTimeout/setInterval/Promises/etc
_callTimer function is called when its time to call a timerID's callback
finding the data of the provided timerID has a dynamic performance characteristic
it depends on how many timers are active at that time due to use of "Array.indexOf"

this change uses a Map lookup to have a constant-time timerID data fetch.

device: Galaxy A32

current: Array.indexOf usage profiling

this PR: Map.get profiling

Changelog:

Pick one each for the category and type tags:

[INTERNAL] [FIXED] - constant time JSTimers/_callTimer

Test Plan:

• packages/react-native/Libraries/Core/Timers/__tests__/JSTimers-test.js tests passes
• setTimeout / setInterval / Promises acts as expected

[facebook-github-bot]

Hi @dagohan!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[javache]

This code is no longer used in the new architecture, so we want to avoid making changes to it unless absolutely necessary.

I assume the profile results were gotten from a benchmark? Could you share this so we can evaluate whether this is a representative scenario for a real-world application?

[dagohan]

I assume the profile results were gotten from a benchmark?

The profiling results were obtained from a real-world app in production (first 12 seconds of startup). Let me know if you need specifics on the benchmarking setup.

[javache]

I'm really curious what your startup path looks like if it takes 12 seconds, and how this timers code makes up 1 second of it!

[dagohan]

actual startup duration is around 8 seconds; profiling captured some post-startup activity
duration varies by device but I tested on Galaxy A32, where the issue is likely more noticeable on low-end android devices.

during startup, a burst of async operations creates many promises and background jobs with intervals, triggering _callTimer frequently - something typical for app startups
the linear search in the growing timerIDs list degrades performance significantly
I've observed it growing to 1000+ items, meaning each _callTimer run can require scanning half the list on average
this results in ~500,000 checks in a worst case, making the cost approach O(n^2)
using a map reduces this to O(1)

this issue isn't limited to startup
indexOf has also shown up as a high-cost center in other flows
I can't share the app's code, but I'm happy to provide any other context needed

[react-native-bot]

This PR is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.

[react-native-bot]

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[react-native-bot]

This PR is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.