[Performance] Class based HOC implementations are costly

[kidroca]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

What performance issue do we need to solve?

• inefficient React component rendering

What is the impact of this on end-users?

• app boot time
• chat switch time

List any benchmarks that show the severity of the issue

1. Start the web app and be on a chat
2. Open the dev console
3. Go to the Performance tab
4. Start capturing data
5. Switch to another chat
6. Wait a few seconds for loading to settle
7. Stop capturing data
8. Review results

• Task 1 - is processing the click and transitioning to another chat - it totals to 868ms for me (Starting on reportID: 71955477)
• A huge part of Task 1 is dedicated to unmounting components - 546ms. All the little needles under unmountHostComponents
  • About ~450 of those are withWindowDimensions HOCs
  • And around 80 are withOnyx HOCs

Profile data (you can load this in Chrome/Performance): https://u.pcloud.link/publink/show?code=XZwvKwXZpXUhxs7Vdr7kaco3HDxznYmcP7sX

Proposed solution (if any)

HOC usages should be gradually reduced as much as possible
They cause 1+ component for each component that uses them

I've described how to change withWindowDimensions here: #2326 (DimensionsContextProvider)
This will leave withWindowDimensions usages throughout the app unchanged, but they will at least not be class based components and would not run class component lifecycle

ReportActionItem should be updated not to be HOC based (if possible) as they are the most rendered component
They can receive window related props from the parent renderItem as well as Onyx related props

List any benchmarks after implementing the changes to show impacts of the proposed solution (if any)

Note: These should be the same as the benchmarks collected before any changes.
This is not at all the final result, but it does show some improvement after converting the withWindowDimensions wrappings not to be class based

Platform:

Where is this issue occurring?

• Web (Affected more due to higher count of HOCs - popups, hoverable items etc...)
• iOS
• Android
• Desktop App (Affected more due to higher count of HOCs - popups, hoverable items etc...)
• Mobile Web

Version Number: 1.0.85-0
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:

View all open jobs on Upwork

[MelvinBot]

Triggered auto assignment to @MonilBhavsar (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[kidroca]

The other large portion of execution time is taken by sendDataToConnection calls
It will be the focus of a separate ticket - #4592
sendDataToConnection should be the easier problem to address as it isolated to Onyx.connect

[kidroca]

cc @marcaaron

[marcaaron]

Should we maybe limit the scope of this to just refactoring withWindowDimensions and create a separate ticket for ReportActionItem?

I'd also be curious to see the effects on chat switching since we have done the test for web but not Android. I'd be curious to see what it does for us on the native side. Is it possible to do a similar trace? I don't have much experience with the hermes debugger but I thought maybe it would be possible to profile there?

[kidroca]

I thought it would be possible to do this with the Hermes debugger in Flipper, but starting the profiler there seems to hang with "Initialising ..."
For Android there's another way - it's part of the development menu. It would create a file, like the one shared here, that you can load inside Chrome
I'll try it and post results

Since all of the hoverable popups should be noop on native, there would be less withWindowDimensions components

After analysing this more the HOCs might only be 30-50% to blame, and the rest is due to the many instances of components that use them.
Most of the withWindowDimensions are used by popups and modals
When we switch to a new chat all the components in the old chat that have componentWillUnmount would run it
For example ContextMenuItem uses willUnmount and so there will be a lot of unmounting going on as each action item would have at least one menu with multiple menu items - that seems to be what's happening in the screenshot I've shared, but originally I've only traced it to withWindowDimensions

Yes the current scope is whatever we can do without massive changes and so far that seems only the withWindowDimensions refactor

We had a test where all popups we removed. Perhaps for a future ticket we can make the same snapshot captured here
and see if this big bar of unmounts gets smaller with no popup components

[marcaaron]

We can just try the withWindowDimensions idea and see what happens - doesn't seem hard to do and we can eliminate it as a potential improvement. Worst case scenario some component will have less overhead. 🤷

[marcaaron]

Managed to get the profiler to work on Android and adding some tips for that in this PR if it helps at all

https://github.com/Expensify/App/pull/4617/files

[MonilBhavsar]

Marc, I assigned you as you are having context and working on this

[MelvinBot]

Whoops! This issue is 2 days overdue. Let's get this updated quick!