Auto-assigning issues to engineers is no longer supported. If you think this issue should receive engineering attention, please raise it in #whatsnext.

cc @sakluger (feel free to assign me as I (or someone from my team) will work on this ticket!)

Curious what is happening with this especially to see if it is related to large numbers of reports (seems likely as there are 15k reports). Gonna assign myself in case @hannojg needs any assistance.

No updates

No update

A large part of this hanging is due to us building the search options the moment we open the search page:

• App/src/pages/ChatFinderPage/index.tsx

  Lines 78 to 91 in 4bac100

  	const searchOptions = useMemo(() => {
  	if (!areOptionsInitialized || !isScreenTransitionEnd) {
  	return {
  	recentReports: [],
  	personalDetails: [],
  	userToInvite: null,
  	currentUserOption: null,
  	categoryOptions: [],
  	tagOptions: [],
  	taxRatesOptions: [],
  	headerMessage: '',
  	};
  	}
  	const optionList = OptionsListUtils.getSearchOptions(options, '', betas ?? []);

I am thinking about how to solve this here, by moving the operations in a first step to a separate thread/web worker:

• https://expensify.slack.com/archives/C05LX9D6E07/p1723454316012939?thread_ts=1723209631.007999&cid=C05LX9D6E07

I just opened a PR hat shows a PoC for using web workers for running the search, which will unblock the main thread:

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

I am now seeking approval on this new technical design here.

(Note: I am OOO for the rest of the week and will continue next week Monday 19.08)

Moving to weekly for now since Hanno is out until Monday.

Can you please also assign @chrispader? he will work on that as well (Chris please comment 🫶 )

Commenting for assignment :)

Thanks for helping, @chrispader. I'll be OOO for the next week. Hopefully we'll have some more details from the investigation when I return!

We were able to reproduce the bigger lags when running on a virtual machine, where the hardware is more constraint than on our recent MacBook Pro models directly. (note: we tested against a recent adhoc build that contained some search improvements).

The thing that takes the most time when opening the search page / chat finder page is:

• calling createOptionsList
• calling getSearchOptions (on the results of createOptionsList)
• calling triggerUnreadUpdate also took ~1-2 seconds

We will come up with solutions for improving the performance of these functions (in the current single threaded architecture).
(Some of these solutions might blend with the solutions we are working on here)

We were able to get another, cleaner, sample of that problem here which relates to creating the options (which causes the lag):

• [Performance] User unable to navigate to chat in search results (slow API call blocks the whole app?) #46593 (comment)

I am sure now that we have a cleaner recording we can come up with good solutions to make this faster!

No updates.

No updates.

No updates

No updates

No updates

No updates

No update

I will try to look into this issue this week!

We've identified one place where the performance can be improved.
When opening the search page we need to construct search options. Part of that step is to order the options.

Opening the full search page takes on my Mac:

Timing:development.new.expensify.open_search 416.6999999284744

For that, we need to create the search options, which makes up for ~70ms of the 416ms:

Timing:development.new.expensify.load_search_options 37.700000047683716
Timing:development.new.expensify.load_search_options 34.200000047683716

Of those 70ms half of the time is spend on ordering the items.

We use lodash order functions, which are known to be slow. We should replace the lodash sort with our own function that is optimized for performance.

Note: the numbers may not seem that drastically as those are from my high end MacBook. The numbers for android on a lower end device are:

Timing:development.new.expensify.load_search_options 790.5101539939642
Ordering options took 475.9423850029707ms
Timing:development.new.expensify.open_search 6194.899076998234

This is only one part of where the time goes for creating the search options, we will continue to where the other time is spend and how it can be optimized.

Edit: It was suspicious that load_search_options was called twice, as it's quite expensive. We put up a PR to address the issue here:

• perf: only call expensive getSearchOptions once #54681