-
Notifications
You must be signed in to change notification settings - Fork 3.2k
[HOLD for payment 2023-10-02] [HOLD] [Performance] ReportScreen unnecessary re-renders #15163
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
Comments
Please assign me for this one 👼 |
This issue has not been updated in over 15 days. eroding to Monthly issue. P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do! |
I think this might one of @hannojg priorities once the Reactions go through some polish |
This issue has not been updated in over 15 days. @hannojg eroding to Monthly issue. P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do! |
@hannojg How is this looking with your other projects? Reactions are almost done |
bumping this to Daily to make sure we investigate this as we are making this component even more robust with manual request so achieving great performance is important |
@mountiny I will pass this task on to @janicduplessis , while I will investigate the performance of other flows in the app. @janicduplessis Despite the title of the issue the goal here is to make the ReportScreen work just fast. |
@janicduplessis Can you please comment on this issue so I can assign you? thank you! |
Sounds good! |
Updated #19345 to only include virtualized list batch size change. |
@janicduplessis to confirm, that does not need to be on hold for the RNW update, right? |
It still does, that was the one fix that needed the RNW update. If we want we could apply the fix only for native if we want to avoid the hold on RNW update. |
Thanks for confirming, now I remember the sidebarData. Thanks! |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.73-1 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-10-02. 🎊 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:
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
|
@janicduplessis, @hannojg, @mountiny Whoops! This issue is 2 days overdue. Let's get this updated quick! |
Triggered auto assignment to @isabelastisser ( |
Bug0 Triage Checklist (Main S/O)
|
Hello @isabelastisser Can you please pay $500 to @sobitneupane for review and testing of this PR? Thanks! |
Requested payment on newDot |
Thanks then we can close this one |
$500 payment approved for @sobitneupane based on this comment. |
Uh oh!
There was an error while loading. Please reload this page.
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
What performance issue do we need to solve?
Right now, every time a report action updates the whole
<ReportActionsList />
will re-render. None of the items that get rendered are memoized. This means that on a single update (e.g. adding a reaction/editing the text) all mounted views of the list will need to re-render.Lets investigate the ReportScreen component tree too as its quite render heavy
What is the impact of this on end-users?
Re-rendering components when its contents haven't changed will in general slow down the app for no good reason
List any benchmarks that show the severity of the issue
None yet
Proposed solution (if any)
This approach might even be faster than the first option, as on an update not all items have to run their arePropsEqual function.
List any benchmarks after implementing the changes to show impacts of the proposed solution (if any)
None yet
Platforms:
Which of our officially supported platforms is this issue occurring on?
Version Number: v1.2.71-1
Reproducible in staging?: yes
Reproducible in production?: yes
Email or phone of affected tester (no customers): N/A
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL: here
Issue reported by: @hannojg
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1675076963206029
View all open jobs on Upwork
The text was updated successfully, but these errors were encountered: