[Performance] Approximate the ideal number of messages to render on first paint based on the screen height

[rdjuric]

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?

This causes unnecessary renders, slow transitions between reports, slow first render of a report.

We're inefficiently guessing that we need to render 20 messages to fill our chat in the first render. In reality the ideal number of messages is based on the screen height of the user, a small chrome window or a mobile device in landscape mode might need as little as 2 messages to fill the chat.

What is the impact of this on end-users?

Chats will load faster - both when changing between chats and when first opening the app.

List any benchmarks that show the severity of the issue

Added to the benchmarks below.

Proposed solution (if any)

In our ReportActionsView, use the screenHeight to calculate the initialNumToRender of our InvertedFlatList.

We can get the ideal initialNumToRender by calculating how much screen space is available for our reports and how much screen space the smallest report possible takes.

In our ReportScreen, we render:

• ReportActionCompose with a minHeight of 90
• HeaderView with a height of 65
• ReportActionsView, with the smallest report possible having 56 of height (40 for the avatar, 16 of padding)

The ideal initialNumToRender can be estimated by (screenHeight - (90 + 65)) / 56. We round the result up to account for cases where there's enough size for a part of another report to show.

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

Benchmarks were run in dev mode, using a simulator for iOS.

1. Start on Concierge chat
2. Switch to another chat with 100+ messages, with 1 IOU and 2 Images in the last 20 messages
3. Check the CONST.TIMING.SWITCH_REPORT
4. Repeat 5 times and calculate the average

Platform	initialNumToRender	Average time to switch reports
Web - Chrome	Fixed (20)	3,795.2 ms
Web - Chrome	Ideal (7)	1,336.2 ms
iOS - iPhone SE	Fixed (20)	7016 ms
iOS - iPhone SE	Ideal (10)	3,888.6 ms

Platform:

Where is this issue occurring?

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number:
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Upwork URL:* https://www.upwork.com/jobs/~01a5045701b75bc097

View all open jobs on Upwork

[MelvinBot]

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

[marcaaron]

This seems like a good idea to me, and the proposed solution makes sense. But I'm also curious if there's some way to save these numbers so they are less magical somewhere. e.g. if the minimum height for a row changes it would be good to have a central variable to control that?

[marcaaron]

Also I think for benchmarks we can use the report switch metric here

App/src/pages/home/report/ReportActionsView.js

Line 329 in e043ac2

Timing.end(CONST.TIMING.SWITCH_REPORT, CONST.TIMING.COLD);

[rdjuric]

But I'm also curious if there's some way to save these numbers so they are less magical somewhere.

Good idea! Maybe instead of hardcoding the numbers we could make our getInitialNumToRender method get the heights necessary for the calculation directly from the the styles of our ReportActionComposer, HeaderView, etc?

This way if we ever change something (like the size of the header or the height of the avatar) our method will still find the ideal number.

Also I think for benchmarks we can use the report switch metric here

Thanks, will add benchmarks soon.

[marcaaron]

Good idea! Maybe instead of hardcoding the numbers we could make our getInitialNumToRender method get the heights necessary for the calculation directly from the the styles of our ReportActionComposer, HeaderView, etc?
This way if we ever change something (like the size of the header or the height of the avatar) our method will still find the ideal number.

Right, I think at a minimum I'm just imagining that the styles in styles.js and these values here would be set in a common place.

I'm not sure the best way to enforce that or how it would work with things like margin and padding (if there is any). Perhaps it will be enough to use some helper functions and leave relevant code comments in the few parts around lists to prevent altering things by adding new styles.

[marcaaron]

aside, I started thinking about this WRT using getItemLayout to optimize the lists that have fixed height elements - and this feels like a similar problem.

[rdjuric]

Updated with benchmarks @marcaaron

Let me know if I should start a PR for this

[marcaaron]

Benchmarks were run in dev mode, using a simulator for iOS.

That data looks promising, but is it possible to do a release build on an actual device? Dev mode + simulator makes it hard to tell exactly how large the difference would be in release. Myself or someone else can try to help with this if not possible for you.

[MelvinBot]

Triggered auto assignment to @trjExpensify (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.