[WIP] WebWorker Demo (to improve search performance) #47432

hannojg · 2024-08-14T15:17:24Z

Fixed Issues

Details

This PR shows how web workers can be used to offload computational heavy work to another thread.
This PR is probably going to be closed and split into multiple smaller PRs, but this is the PoC implementation.

Demo

Screen.Recording.2024-08-14.at.16.59.47.mov

How the new API works in the expensify code

We can simply replace our useMemos that do computational heavy work with useWorkerMemo:

- const newOptions = useMemo(() => {
-	 return OptionsListUtils.filterOptions(searchOptions, debouncedSearchValue, {sortByReportTypeInSearch: true, preferChatroomsOverThreads: true});
- }, [searchOptions, debouncedSearchValue])

+ const newOptionsData = useWorkerMemo(
+     workerFilterOptions,
+      [searchOptions, debouncedSearchValue, {sortByReportTypeInSearch: true, preferChatroomsOverThreads: true}]
+ );

The difference is that the function we want to invoke in our useWorkerMemo needs to be defined in a separate file (to conform to how web workers work on web). This function here is called workerFilterOptions and is defined like this:

const workerFilterOptions = createWorkerFactory(() => new Worker(new URL('@libs/worker/exampleWorker.ts', import.meta.url)));

createWorkerFactory is basically a helper function that creates a new worker, which is loaded from the URL provided (which points to a new file in our code which exposes the worker function).

Lets have a look at how exampleWorker.ts is implemented:

import * as FilterListUtils from '@libs/FilterListUtils';
import type {FilterOptionsConfig, Options} from '@libs/OptionsListUtils';
import {expose} from '@libs/Worker';

const worker = expose((options: Options, searchInputValue: string, config?: FilterOptionsConfig) => {
    return FilterListUtils.filterOptions(options, searchInputValue, config);
});

export default worker;

A worker is exported that uses our expose API. expose is used to define a function. That is the function our useWorkerMemo "will call" (though web worker APIs).
It basically just forwards a call to a library utility of ours for filtering the search results.

Note

I choose this API as it:

Hides the raw web worker APIs which can be complex to think about
Provides a way to easily migrate an existing useMemo to an offloaded one
Provides a way to also provide a mobile implementation (that will use something else than web workers)

Now, as our computation happens on another thread, the data retrieval is asynchronous. Thus useWorkerMemo can't directly return the data. Instead it returns an object that is either:

{
	state: "loading"
}

while we are requesting data or its:

{
	state: "data"
	result: [...] // the data we computed
}

There is also an error state in case the worker function had any problems.
Using this data we can display a loading UI while we wait for the data.

How it can work on mobile

Web Workers is an API only available on the web/desktop. For mobile we'll need a different implementation. The idea is to still use the same API on mobile, but the implementation details will be different.

Running code on a separate thread is something we already do in expensify: we use "worklet" functions from reanimated to run on the UI thread.

However, for those extra computations we don't won't to run them on the UI thread, but a special separate thread. Additionally reanimated worklets lack some functionality such as being able to return a value from the worklet function.

At Margelo we developed react-native-worklets-core, which works very similar to the worklets we know from reanimated.
However, with react-native-worklets-core we can run on different threads and return values from our worklets. Additionally in react-native-worklets-core we can support loading code from custom bundles (which reanimated worklets can't). This way we can implement the "workers" on mobile as follows using worklets:

We simply add the worklet directive to our worker:

// ..
import {expose} from '@libs/Worker';

const worker = expose((options: Options, searchInputValue: string, config?: FilterOptionsConfig) => {
+  "worklet";
    return FilterListUtils.filterOptions(options, searchInputValue, config);
});

We'd construct our worker factory differently on mobile:

const workerFilterOptions = createWorkerFactory(async () => {
  "worklet";
  return await import('@libs/worker/exampleWorker.ts');
}));

react-native-worklets-core will taking care of creating a separate bundle that can be imported at runtime.
Internally in useWorkerMemo instead of using the message pattern from the web workers, we will simply call our worklet function:

const result = await context.runAsync(() => {
  'worklet'
  return ourExposedFunction(...args)
})
// The result now has the value on the JS thread!

Currently the library doesn't support await import which we'd need. We reckon that implementing this behaviour would take between 3-5 days.

Next steps

First I want to agree with engineers about the design choice for web workers.
Make a PR that adds the useWebWorker, expose, createWorkerFactory, etc API
Make PR to split out the filterOptions function
- The problem is that the filterOption functions lives in OptionListUtils which is huge and imports API code that imports pusher, which depends on window., which is not available in workers. It would be a waste to include so much code in our worker anyway.
- Thats the reason why I created this separate FilterListUtils utility, as it contains the filterOptions function isolated.
Make a PR to use filterOptions with useWorkerMemo
Make PR to use OptionsListUtils.getSearchOptions with useWorkerMemo (thats also quite heavy and blocking the search page)
Discuss ways how to implement that on mobile (I already have an idea for a PoC which I can present once we are done here on the web part)

Fixed Issues

$ #46591
PROPOSAL: https://expensify.slack.com/archives/C05LX9D6E07/p1723454316012939?thread_ts=1723209631.007999&cid=C05LX9D6E07

Tests

Verify that no errors appear in the JS console

Offline tests

QA Steps

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

hannojg · 2024-08-22T07:53:49Z

#46591 (comment)

hannojg added 9 commits August 12, 2024 15:55

wip: web worker

4aa066c

first working web worker

169d6a2

correct worker type

e6c7878

complete example for filterOptions

8b1250b

removed logs

087a035

as const to fix TS error

6b0844b

enable timing again

fa145ee

remove debug code

80b454b

restore idnex setup

d93f16c

hannojg closed this Aug 22, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] WebWorker Demo (to improve search performance) #47432

[WIP] WebWorker Demo (to improve search performance) #47432

hannojg commented Aug 14, 2024 •

edited

Loading

hannojg commented Aug 22, 2024

[WIP] WebWorker Demo (to improve search performance) #47432

[WIP] WebWorker Demo (to improve search performance) #47432

Conversation

hannojg commented Aug 14, 2024 • edited Loading

Fixed Issues

Details

Demo

How the new API works in the expensify code

How it can work on mobile

Next steps

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

hannojg commented Aug 22, 2024

hannojg commented Aug 14, 2024 •

edited

Loading