-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[HOLD for payment 2024-01-03] [HOLD for payment 2023-12-28] [Performance] Search input performance optimization #32806
Comments
Triggered auto assignment to @kadiealexander ( |
Bug0 Triage Checklist (Main S/O)
|
Hi, I'm Tomasz from Callstack and I'd like to work on that issue |
Not overdue! |
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results. If a regression has occurred and you are the assigned CM follow the instructions here. If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future. |
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results. If a regression has occurred and you are the assigned CM follow the instructions here. If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future. |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.14-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2023-12-28. 🎊 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.
For reference, here are some details about the assignees on this issue:
|
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:
|
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results. If a regression has occurred and you are the assigned CM follow the instructions here. If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future. |
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.17-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2024-01-03. 🎊 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.
For reference, here are some details about the assignees on this issue:
|
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:
|
This is new feature and performance related I think no regression tests are needed we are working on new automated perf tests |
Coming from this performance proposal:
Problem:
Currently, when users type in the search input in Money Request Participant List search, each keystroke triggers re-rendering of Option List, which is preceded by heavy calculations in the getOptions function, leading to significant performance overhead. Comparing the execution time of this function on Web:
With keystrokes calling such expensive function, this results in a laggy user experience, as the app processes each input individually without any delay or optimization. The continuous processing of these inputs strains the app’s resources, causing slowdowns and delays in displaying search results.
Additionally, each keystroke is causing unnecessary re-renders in the list items that could be avoided to reduce the consumption of the CPU.
### Solution:
To address this problem, we could do a few steps that should positively impact the usage of search:
Comparing the results on the account with 15330 reports on Web:
Action: write adg in the search
Metric: getOptions call count Before: 4 After: 1
Metric: max JS heap Before: 595mb After: 306mb
Metric: MoneyRequestParticipantSelector max render time Before: ~110ms After: ~75ms
Metric: Single list item render count Before: 4 After: 1
Comparing account with 4200 personal details on Android - you can see attached screenshot of CPU usage from Flashlight. The blue line indicates the CPU usage while writing my email address “tomasz.misiukiewicz@callstack.com” and having getOptions method called on each keystroke. CPU usage for JS thread is around 100% all the time. The yellow line indicates CPU usage when calling getOptions function is debounced - the usage jumps only when there was a pause in typing longer than the debounce time.
This changes will also benefit other lists using OptionsSelector component:
Few of them already have debouncing implemented, but they have different amount of milliseconds set, so we can unify them. Additionally each one of them will benefit from reduced amount of re-renders of list items.
The text was updated successfully, but these errors were encountered: