-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
[Audit][Implementation] - Memoize SidebarLinksData #37205
[Audit][Implementation] - Memoize SidebarLinksData #37205
Conversation
activeWorkspaceID, | ||
policyMemberAccountIDs, | ||
); | ||
const reportIDs = optionItemsMemoized; | ||
|
||
if (deepEqual(reportIDsRef.current, reportIDs)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this additional layer still valid?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a comment just below which explains about updating the reportIDsRef
. But I think it's not adding any value 🤔 We might try to remove this layer altogether and see if it's not producing any weird output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the comment for this layer:
// 1. We need to update existing reports only once while loading because they are updated several times during loading and causes this regression: https://github.com/Expensify/App/issues/24596#issuecomment-1681679531
// 2. If the user is offline, we need to update the reports unconditionally, since the loading of report data might be stuck in this case.
// 3. Changing priority mode to Most Recent will call OpenApp. If there is an existing reports and the priority mode is updated, we want to immediately update the list instead of waiting the OpenApp request to complete
It is fixing some regression or bug form the past, I didn't want to mess with it and kept it as it was
@@ -334,4 +330,22 @@ export default compose( | |||
initialValue: {}, | |||
}, | |||
}), | |||
)(SidebarLinksData); | |||
)( | |||
memo( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on how this looks like it'd be worth to comment it well in code - what these checks represent, why we need them so that it's easier to remove this once we solve the root cause later on.
We are holding this off until we complete the remaining audit implementations because as of now, we have the following results from this PR and we are not yet sure whether we prefer the extra render without memo or increased rendering time with memo. We will evaluate this after all the audit action items are completed. Here are the renders times: with memo:
without memo:
|
After finishing the remaining part of audit implementation we did the measures again. After memo -> 22899ms Gain -> 1804ms with memoizing that component we can get around ~2s on app startup on heavy account. Please see for details and hermes traces on the PR description. |
@Santhosh-Sellavel Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
(prevProps, nextProps) => | ||
_.isEqual(prevProps.chatReports, nextProps.chatReports) && | ||
_.isEqual(prevProps.allReportActions, nextProps.allReportActions) && | ||
prevProps.isLoadingApp === nextProps.isLoadingApp && | ||
prevProps.priorityMode === nextProps.priorityMode && | ||
_.isEqual(prevProps.betas, nextProps.betas) && | ||
_.isEqual(prevProps.policies, nextProps.policies) && | ||
prevProps.network.isOffline === nextProps.network.isOffline && | ||
_.isEqual(prevProps.insets, nextProps.insets) && | ||
prevProps.onLinkClick === nextProps.onLinkClick && | ||
_.isEqual(prevProps.policyMembers, nextProps.policyMembers) && | ||
_.isEqual(prevProps.transactionViolations, nextProps.transactionViolations) && | ||
_.isEqual(prevProps.currentUserPersonalDetails, nextProps.currentUserPersonalDetails) && | ||
prevProps.currentReportID === nextProps.currentReportID, | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can we make sure there is no condition missing in the memo for the SidebarLinksData? Last time we added memo like this with @hurali97 there was bunch of props cases we missed and they caused regressions.
Did we add all the props here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added all the props that are coming to this component, also I noticed that when I missed some of them e.g. currentReportId
or currentUserPersonalDetails
the jest tests failed - it might be the indicator if we miss some props
@Santhosh-Sellavel are you able to test this one today? |
@mountiny I guess not please reassign. |
App crashing with following steps
crashSideBar.mp4Edit: Merging |
Reviewer Checklist
Screenshots/VideosAndroid: NativesideBarPerfAndroid.mp4Android: mWeb ChromesideBarPerfAndroidmWeb.mp4iOS: NativesideBarPerfiOS.mp4iOS: mWeb SafarisideBarPerfiOSmWeb.mp4MacOS: Chrome / SafarisideBarPerfChrome.mp4MacOS: DesktopsideBarPerfDesktop.mp4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
Details
Part of Callstack Performance Audit
The PR memoizes the SidebarLinksData, with that we can reduce calls
getOrderedReportIDs
.TTI of App startup:
Baseline -> 24703ms
After memo -> 22899ms
Gain -> 1804ms
Here are the hermes traces, as you can see after memoizing the component function getOrderedReportID is called 3 times instead of 5
Baseline:
With memo:
Fixed Issues
$ #38055
PROPOSAL: #35234 (comment)
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodWaiting for Copy
label for a copy review on the original GH to get the correct copy.STYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android.mp4
Android: mWeb Chrome
And-web.mp4
iOS: Native
iOS.mp4
iOS: mWeb Safari
iOS-web.mp4
MacOS: Chrome / Safari
Web.mp4
MacOS: Desktop
Desk.mp4