[$500] Investigate options for Storage eviction in Onyx

[mountiny]

Coming from here, some users might end up with very large onyx states locally, which is not necessary in most cases, as the majority of the data will never be accessed again.

Let's investigate if storage eviction in Onyx can bring us any meaningful gains. Cache eviction is important, but how does the size of the stored Onyx data influence performance? That is not clear. Let's find out.

[kpadmanabhan]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Onyx Cache eviction mechanism and potential performance improvements because of smaller size of Onyx data.

What is the root cause of that problem?

No Onyx eviction policy and mechanism in place, which leads to certain users having very large Onyx states.

What changes do you think we should make in order to solve the problem?

• Clear all data from Onyx upon logout.

function signOut() {
    Onyx.clear();
}

• storage eviction documentation from Onyx documentation https://www.npmjs.com/package/react-native-onyx/v/1.0.71

Storage Eviction
Different platforms come with varying storage capacities and Onyx has a way to gracefully fail when those storage limits are encountered. When Onyx fails to set or modify a key the following steps are taken:
Onyx looks at a list of recently accessed keys (access is defined as subscribed to or modified) and locates the key that was least recently accessed
It then deletes this key and retries the original operation
By default, Onyx will not evict anything from storage and will presume all keys are "unsafe" to remove unless explicitly told otherwise.
To flag a key as safe for removal:
Add the key to the safeEvictionKeys option in Onyx.init(options)
Implement canEvict in the Onyx config for each component subscribing to a key
The key will only be deleted when all subscribers return true for canEvict

Onyx.init({
    safeEvictionKeys: [ONYXKEYS.COLLECTION.REPORT_ACTIONS],
});

export default withOnyx({
    reportActions: {
        key: ({reportID}) => `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}_`,
        canEvict: props => !props.isActiveReport,
    },
})(ReportActionsView);

• Also consider this while using collections for storage

Be cautious when using collections as things can get out of hand if you have a subscriber hooked up to a collection key that has large numbers of individual keys.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Write performance tests specifically for Onyx access. Refer section 'Benchmarks' from https://www.npmjs.com/package/react-native-onyx/v/1.0.71 for recording Onyx access times.

What alternative solutions did you explore? (Optional)

N.A.

[mountiny]

Not looking for proposals here, thanks

[kubabutkiewicz]

Hey, update on that I created a draft PR with POC for implementation of storage eviction, right now I am doing an investigation about how big onyx states impact on the perf. I was trying to add a module which will calculate the amount of the operations made in the onyx when we more data in onyx vs less (after eviction) but I noticed that its adding overhead for the js and the results are false/positive. So I switched to different way of the investigation, I just used app normally for 5 mins with and without eviction and then I am measuring different scenarios using comparing traces script. and this is a result of for example switching report in LHN

I am checking different scenarios and why less data in onyx is having the impact on the render times
@mountiny I will be ooo from tomorrow to the end of the week do you want me to ask somebody to take over?

[mountiny]

@kubabutkiewicz that is ok, feel free to keep investigating this yourself.

Looks promising

[melvin-bot]

@kubabutkiewicz Whoops! This issue is 2 days overdue. Let's get this updated quick!

[kubabutkiewicz]

Hey I am back from ooo will continue on the investigation

[kubabutkiewicz]

Update on that:
I did more tests today and results are not 100% obvious, there are cases when less data in storage equals better perf but not every time. I did tests on the same account straight after login in and after using it for some time (straight after login I had ~2400 items in indexdb and after some time of usage ~4200) The tests which I did were

1. App load after refresh
2. Switch report
3. Switch 3 reports
4. Open expense

and here are the results

App load seems to be almost the same for big vs small states and opening of 3 different reports seems to be more performant when we have more data in the state I will check it again because this doesnt make sense but for different tests its seems to be better for render time when we have less data in the onyx.

As of now I identified 2 culprits in onyx codebase

1. fastMerge we are calling this method on every key in onyx few times even though obejcts are not changing and we are marging smae object, so maybe there is a way to optimize it so we would call it only when there is a change
2. subscribeToKey we are looping thorugh every key in the onyx we are maybe not doing anything expensive there but we are calling this many times especially during reloads of the app I put the log before looping and I saw this log 8 times so we did loop through ~2400 items (in small onyx state case) 8 times so if we have bigger states it can be more problematic

[mountiny]

Ok so far we cannot say this would bring significant gains