[Performance] [Audit] `withOnyx` causes bursts of commits, impeding performance

[jsamr]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

This report is part of #3957, scenario "Rendering Individual chat messages".

Commit log excerpt

The full commit log can be inspected with Flipper or React Devtools, see #3957 (comment) for instructions. This excerpt takes only the first 31 commits of the 292-long log.

SHOW LOG

1. Renders BaseNavigationContainer because of hook change (124ms)
2. Renders BaseNavigationContainer because of hook change, but don't re-renders subtree (6ms)
3. Renders withOnyx(Component) because preferredLocale state changed (0.1ms)
4. Renders withOnyx(Component) because loading state changed (0.2ms)
5. Renders SideBarLinks (withOnyx) because currentlyViewedReportID prop changed (12ms)
6. Renders withOnyx(HeaderView) because report state changed (0.1ms)
7. Renders withOnyx(HeaderView) because personalData state changed (0.1ms)
8. Renders withOnyx(HeaderView) because policies state changed (0.1ms)
9. Renders withOnyx(HeaderView) because loading state changed (13.2ms)
10. Renders withOnyx(Component) inside HeaderView because preferredLocale state changed (0.1ms)
11. Renders withOnyx(Component), parent of VideoChatButtonAndMenu because loading state changed (5.8ms)
12. Renders ReportScreen because isLoading state changed (13ms)
13. no apparent cause (NAC)
14. Renders withOnyx(ReportView), because state changed session (0.1ms)
15. Render withOnyx(ReportView), because state changed loading (3.6ms)
16. Render withOnyx(ReportView), because state changed preferredLocale (0.1ms)
17. Render withOnyx(Component), list cell, because state changed loading (0.6ms)
18. Render withOnyx(Component), list cell, because state changed preferredLocale (0.1ms)
19. Render withOnyx(Component), list cell, because state changed loading (0.1ms)
20. Render withOnyx(ReportActionView), list cell, because state changed report (0.1ms)
21. Render withOnyx(ReportActionView), list cell, because state changed reportActions (0.1ms)
22. Render withOnyx(ReportActionView), list cell, because state changed session (0.1ms)
23. Render withOnyx(ReportActionView), list cell, because state changed loading (19ms)
24. Render withOnyx(ReportActionCompose), list cell, because state changed comment (0.1ms)
25. Render withOnyx(ReportActionCompose), list cell, because state changed betas (0.1ms)
26. Render withOnyx(ReportActionCompose), list cell, because state changed modal (0.1ms)
27. Render withOnyx(ReportActionCompose), list cell, because state changed network (0.1ms)
28. Render withOnyx(ReportActionCompose), list cell, because state changed myPersonalDetails (0.1ms)
29. Render withOnyx(ReportActionCompose), list cell, because state changed personalDetails (0.1ms)
30. Render withOnyx(ReportActionCompose), list cell, because state changed reportActions (0.1ms)
31. Render withOnyx(ReportActionCompose), list cell, because state changed report (0.1ms)
    ...

#4022 could be related to this

withOnyx HOC triggers a lot of commit bursts such as seen in the commit log excerpt. You can also notice this pattern with the commit graph in Flipper / Devtools:

In the below graph, we see that from commit 24 to 52, a span of 400ms was occupied by those commit bursts, happening for each cell. This will cause performances issues because React needs to run its reconciliation algorithm each time setState is invoked. Moreover, each commit can cause children to re-render unless they are pure (and assuming props are memoized). withOnyx is so widespread in this application that every commit must count!

Proposal 1: batch Onyx state mutations

Proposal: Perhaps events could be initially batched to avoid these bursts. For example, we could cache every subscribed key and trigger a state update only when all keys have been loaded.

Proposal 2: avoid extraneous tailing commit (loaded state becomes true)

withOnyx HOC causes at least n + 2 commits, where n is the number of subscribed keys (initial, ...nth key available, and loaded). With Proposal 1, we could go down to at least 3 commits (initial, first batch, loaded). We could go down to 2 if loaded came along with the first batch.

If proposal 1 cannot be considered, we could still spare one commit by using getDerivedStateFromProps to derive loaded.

Proposal 3, access cache synchronously to prevent extraneous commits

Onyx has a cache which returns cached values as promises.

https://github.com/Expensify/react-native-onyx/blob/86be75945a47f9015b9a37ca738e8fdd36e42de3/lib/Onyx.js#L40

If it would return cached values synchronously, we could set some keys early (in withOnyx constructor) and in many instances where all keys are cached, end up with only one initial render (if we include the first two proposals) instead of the current n + 2 figure.

Proposal 4, test rendering performance of withOnyx

Test performance-critical withOnyx with react-performance-testing to enforce rendering metrics, such as number of renders in controlled conditions.

Proposal 5, (experiment) use React Context for keys that change rarely

A lot of components subscribe to keys which rarely change (preferredLocale, session, beta). If the first 3 proposals could not be considered, an alternative would be to limit the number of components subscribing directly to Onyx, and use a store to share access to these values which rarely change and have a low memory footprint. Thus, most of those components would require one render instead of the n + 2 pattern identified before.

The context would be connected to Onyx, and update slices of its state on value updates. Moreover, you could also take advantage of useContextSelector third party which should land to React soon, narrowing down subscriptions to slices of the state.

EDIT 1: Added Proposal 4
EDIT 2: Added Proposal 5

[MelvinBot]

Triggered auto assignment to @stephanieelliott (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[marcaaron]

Proposal 1: batch Onyx state mutations

This is an interesting idea, but I'm not yet sure how it would work given the architecture we have now. Let's dive a little deeper...

Presently, we are calling setState() directly on any connected components (which we store references to in a subscriber map) in several places. When a stored key changes we will loop over the map and setState() on each subscriber. These updates could be batched maybe, but I think the intention here was that it would be ideal to update a subscriber as soon as the data changes or is fetched from storage asynchronously (since "asynchronous" would always be better than "synchronous").

That said, I think what we are looking at here in the profile is the state when a withOnyx component first mounts and calls Onyx.connect() for each key. So without changing too much we could start by changing the logic in withOnyx where we send the data to a connection. So that for the connected components we:

1. Gather all this data from AsyncStorage or the cache
2. Call withOnyxInstance.setState() once

Proposal 2: avoid extraneous tailing commit (loaded state becomes true)

Doing the above should allow us to also set loaded when the rest of the data is set and we won't need to do the dance where we wait for data to become available and then perform another state update.

Proposal 3, access cache synchronously to prevent extraneous commits

I'm not too sure how to reliably achieve this without creating a big front-loaded event where all data from storage is first pulled into the cache on app init, but maybe there's some other way or that's not a real problem.

I think the main arguments why we have not done it is:

1. memory cache will, well, take up a lot of memory
2. it will add extra lag to app boot time while we slurp up all the data from storage into the cache

Maybe @kidroca has thoughts on this. I think if the rendering trade-offs of being able to go from n+2 commits to n+1 then eventually to n are great enough then we can compare that to the cost of app boot + memory consumption. I'm not sure anyone has evaluated whether those are real or imagined problems - and maybe if they are real there are other ways to solve them.

Proposal 5, (experiment) use React Context for keys that change rarely

This sounds interesting. I'm less familiar with how a solution like this might work and having trouble seeing how it would fit in with the logic we already have.

Does it kind of beg the question of whether we should just be using context for everything? Seems like this is what Redux uses. And makes me wonder whether switching from the setState() on a subscriber model should not be replaced with a context solution - and what that would look like.

[kidroca]

Proposal 1: batch Onyx state mutations

This sounds like a case for the initial connection (mount time)
withOnyx would have to wait to get everything from storage and then render the wrapped component
This is perceived like something slow compared to render a prop as soon as possible, but if
all props need to come from disc or from cache - they will take about the same time to arrive so we might as
well wait for that. The only time a prop can come significantly faster is when one comes from cache and the
other from storage, but IMO it's still worth to wait all to arrive

Something very similar happens for subscriptions to collection keys

@marcaaron I somewhat did this with multiGet, but preserved the logic
that called keysChanged in a foreach
I just want to note that this is something that would probably go hand in hand with get/multiGet batching

Proposal 2: avoid extraneous tailing commit (loaded state becomes true)

If loading can be derived without using state then this make sense

Proposal 3, access cache synchronously to prevent extraneous commits

After initially adding cache we triggered keysChanges synchronously.
It resulted in bugs through the app we added Promise.resolve() to
preserve the previous async behavior
Though this might work if serves only to get data

Proposal 5, (experiment) use React Context for keys that change rarely

I'm making updates that would keep some keys like defaultKeyStates forever in cache
they take low space and are frequently fetched, we could identify all such keys and
add them to this list/map

---

Does it kind of beg the question of whether we should just be using context for everything?

On the broader topic of Context I thought of that as well
Why don't we have a store in memory (promote cache or succeed it)
It doesn't have to contain all the items we have on disc, just whatever is used ATM
Components can connect directly to it and receive the data
Writes/merges are first sent there and then a patch is sent to disc
Any updates to it would cause a re-render and pass the changes down without having to maintain an explicit connection
This is where redux suffered in the past, and where the store can be divided into multiple
substores, so that updating one would not cause a re-render to components that aren't subscribed to keys from this substore
It's a long topic...

[jsamr]

@kidroca

This is where redux suffered in the past, and where the store can be divided into multiple
substores, so that updating one would not cause a re-render to components that aren't subscribed to keys from this substore

This is precisely where useContextSelector comes to the rescue! (see Proposal 5)

[MelvinBot]

Triggered auto assignment to @chiragsalian (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.