[Due for payment 2025-08-11] [Due for payment 2025-08-05] [$250] [Due for payment 2025-07-25] Investigate createOnyxProvider performance

[roryabraham]

Coming from: https://expensify.slack.com/archives/C05LX9D6E07/p1747410805866429

Background

When createOnyxProvider was first added, it came with a big performance boost; when we had many identical withOnyx calls on components that were rendered many times, then any time the Onyx data changed, we had to do N callbacks to update all the subscribers, which led to N setState calls and N independent re-renders. This was inefficient and jammed up React. By creating a central subscriber and propagating state updates throughout the app using the Context API, things became more performant.

However, things have changed since then:

• We have the OnyxConnectionManager that ensures multiples useOnyx reuse the same subscription when connecting to the same key. However, each of the subscriber callbacks are still executed, so it's unclear if this is functionally the same as having a single subscriber, then propagating changes with the Context API, or if there's a still a performance difference.
• We use hooks instead of HOCs now, and useOnyx uses useSyncExternalStore which is, in terms of performance and state updates, more suited to integrating with external stores (like Onyx) than setState was
• React has built-in render batching now too, which wasn't present when createOnyxProvider was added

Problem

When we have multiple similar methods to manage state without clear guidelines on when to use which, it leads to developer and reviewer overhead. The code may be more complex than it needs to be, but it generally seems like nobody knows whether that's true or not.

Solution

Investigate the performance impact of createOnyxProvider v.s. just directly using useOnyx. Report back so that we can decide on next steps:

• Do nothing, OR
• Document the result and provide guidance on when createOnyxProvider should be used and when it should not, OR
• Investigate if we can build the performance optimization of createOnyxProvider globally into react-native-onyx, OR
• Remove createOnyxProvider if it's not serving any purpose anymore

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021948296472514036129
• Upwork Job ID: 1948296472514036129
• Last Price Increase: 2025-07-24

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @twisterdotcom

[zirgulis]

Hi I'm Povilas from Callstack and I would like to work on this issue

[roryabraham]

@zirgulis any update here?

[zirgulis]

@roryabraham I did quite a bit of profiling and want to share my findings.

As it was suggested here my initial plan was to replace usePersonalDetails hook with useOnyx(ONYXKEYS.PERSONAL_DETAILS_LIST, {canBeMissing: false}) in the codebase and see the impact to rendering. I also commented out PersonalDetailsProvider:

For that we need a flow which will update the data in the onyx key ONYXKEYS.PERSONAL_DETAILS_LIST. Split expense flow is great for that.

Steps taken to profile (Web):

1. Press “Split Expense”
2. Enter amount, press Next
3. Press “Start profiling” in React devtools
4. Go back to request amount step, press “Split 20 usd”
5. Stop the profiling in React devtools

Stats:
1️⃣ File 1: withOnyx.json
• Commit count: 41
• Total render duration: 418.1000000000002 ms
• p50 / p95 / p99 (ms):
• p50: 1.3 ms
• p95: 45.2 ms
• p99: 132.6 ms
2️⃣ File 2: useOnyx.json
• Commit count: 39
• Total render duration: 353.00000000000006 ms
• p50 / p95 / p99 (ms):
• p50: 1.5 ms
• p95: 38.7 ms
• p99: 134.2 ms
=== 📊 Comparison ===
🟢 Total Duration Difference: -65.100 ms
🟢 Render Count Difference: -2

Having useOnyx instead of usePersonalDetails on web made a slight performance improvement. However, I wanted to check if this has any impact on mobile, particularly on slow to render interactions like bottom tab switching on Android.

Steps when profiling (Android):
Inbox screen -> Reports screen -> Inbox screen

1️⃣ File 1: android_withOnyx_tab_switch.json
• Commit count: 30
• Total render duration: 2451.508 ms
• p50 / p95 / p99 (ms):
• p50: 46.517 ms
• p95: 240.765 ms
• p99: 538.08 ms

2️⃣ File 2: android_useOnyx_tab_switch.json
• Commit count: 31
• Total render duration: 3056.3759999999997 ms
• p50 / p95 / p99 (ms):
• p50: 61.787 ms
• p95: 304.981 ms
• p99: 443.295 ms

=== 📊 Comparison ===
🔴 Total Duration Difference: 604.868 ms
🔴 Render Count Difference: 1

It resulted in +600ms time to render when switching tabs, which is a major regression. The results on iOS were better but still bad, resulting in +197ms to render.

After consulting with @fabioh8010 , we decided to replace withOnyx with useOnyx in createOnyxContext.tsx and compare the results with main (diff).

Android

1️⃣ File 1: main_tab_switch_android.json
• Commit count: 31
• Total render duration: 2488.8319999999994 ms
• p50 / p95 / p99 (ms):
• p50: 48.328 ms
• p95: 281.943 ms
• p99: 424.7 ms

2️⃣ File 2: android_useOnyx_in_provider.json
• Commit count: 27
• Total render duration: 1943.4699999999998 ms
• p50 / p95 / p99 (ms):
• p50: 53.777 ms
• p95: 197.585 ms
• p99: 265.568 ms

=== 📊 Comparison ===
🟢 Total Duration Difference: -545.362 ms
🟢 Render Count Difference: -4

iOS

1️⃣ File 1: main_tab_switch_ios.json
• Commit count: 38
• Total render duration: 1695.1790000000003 ms
• p50 / p95 / p99 (ms):
• p50: 15.783 ms
• p95: 163.06 ms
• p99: 256.253 ms

2️⃣ File 2: ios_useOnyx_in_provider_2.json
• Commit count: 36
• Total render duration: 1637.127 ms
• p50 / p95 / p99 (ms):
• p50: 29.819 ms
• p95: 200.874 ms
• p99: 235.836 ms

=== 📊 Comparison ===
🟢 Total Duration Difference: -58.052 ms
🟢 Render Count Difference: -2

We saw a significant performance boost on Android with 545ms less in total render time while switching tabs. We believe the majority of render commits were taking less time because there were less onyx callbacks to hit with a single subscription per context versus multiple callbacks per many components.

[roryabraham]

Ok, so one clear take-away is that replacing withOnyx with useOnyx within createOnyxContext results in a performance improvement. This isn't a big surprise.

But it seems to me that another take-away is that propagating Onyx state with context rather than useOnyx is still substantially faster. In the first experiment, we may be able to chalk the performance improvement of useOnyx over createOnyxContext to be due to the use of withOnyx inside createOnyxContext.

So is it accurate to say that, in all experiments so far, using createOnyxContext with useOnyx internally is the most performant implementation?

[zirgulis]

So is it accurate to say that, in all experiments so far, using createOnyxContext with useOnyx internally is the most performant implementation?

Absolutely. In both experiments (bottom tab switch and split expense) we saw the best render times when using useOnyx in createOnyxContext.

@roryabraham should I create a PR with these changes?