[HOLD for payment 2023-12-29] [HOLD for payment 2023-11-13] [$500] Optimize SearchPage component to reduce lags when opening

[mountiny]

Coming from here

Proposal: Optimize SearchPage component to reduce lags when opening

Problem: When opening the SearchPage component using search icon or cmd+k shortcut on web, the animation is pretty laggy. This is caused mostly by OptionsListUtils.getSearchOptions which takes all reports as a param and at some point it processes it by looping through all the elements. For an account with ~15k reports, this loop takes up to 500ms. What’s worth noticing, OptionsListUtils.getSearchOptions is called directly in SearchPage constructor, and it’s responsible for retrieving the data that gets set as an initial state values.

Solution: To prevent doing heavy calculations on the same time as transitioning, we should remove calling getSearchOptions from constructor and set default values to empty objects. Instead, we can load this data right after transition ends by using onEntryTransitionEnd prop in ScreenWrapper. With this solution, animation will be smooth and user will be presented with the skeleton unless the data is processed. In my measurements, it reduced the time for initial render of SearchPage from ~1400ms to ~76ms. While profiling, JS Heap went down from 435-840mb range to 90-450mb.

cc @TMisiukiewicz

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~017fbfc71ea6da3266
• Upwork Job ID: 1716834699820085248
• Last Price Increase: 2023-10-24

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~017fbfc71ea6da3266

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @robertKozik (External)

[mountiny]

Sorry @laurenreidexpensify matt is ooo now

[TMisiukiewicz]

hi, I'm Tomasz from Callstack and I'd like to work on this issue

[cubuspl42]

@mountiny What's the relation between this issue and #28071? I'm not completely sure why this one was created.

[TMisiukiewicz]

@cubuspl42 I think #28071 is focusing on the delay between Search page being open and focusing on the input - the setTimeout with CONST.ANIMATED_TRANSITION mentioned in the issue is the reason it happens. It happens for all users, regardless of the amount of the data being used in the Search page. This issue is focusing more on the accounts where there is a lot of data - I have tested it with an account with ~10k reports and ~15k personal details being loaded and there is a noticeable lag between pressing cmd+k and opening the search page. So I think it's worth to treat lag between pressing cmd+k and opening the page and delay in focusing on the input as separate issues

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.95-9 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• perf: improve performance when opening Search with cmd+k #30263

If no regressions arise, payment will be issued on 2023-11-13. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @TMisiukiewicz does not require payment (Contractor)
• @robertKozik does not require payment (Contractor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@robertKozik] The PR that introduced the bug has been identified. Link to the PR:
• [@robertKozik] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@robertKozik] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@robertKozik] Determine if we should create a regression test for this bug.
• [@robertKozik] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@muttmuure] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[mallenexpensify]

Commenting here cuz I reported a similar, or the same issue here

• CRITICAL: Desktop - Chat Switcher is slow and doesn't recognize keystrokes #28071 (comment)

The problem I'm running into regularly now, on Desktop v1.3.96-10 is that the first character isn't showing up, but the overall speed seems to be improved.

Also, reopening cuz I think think we need a payment breakdown, checking internally if they're needed when the only contributors are from agencies.

[mountiny]

Not needed, closing

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.15-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• [CP Staging] Fix/searchpage optimization #33399

If no regressions arise, payment will be issued on 2023-12-29. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @TMisiukiewicz does not require payment (Contractor)
• @robertKozik does not require payment (Contractor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@mountiny] The PR that introduced the bug has been identified. Link to the PR:
• [@mountiny] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@mountiny] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@TMisiukiewicz / @robertKozik] Determine if we should create a regression test for this bug.
• [@TMisiukiewicz / @robertKozik] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@muttmuure] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: