[Due for payment 2025-10-28] Investigate account performance with many expenses to submit and approve

[mountiny]

Details in this thread https://expensify.slack.com/archives/C05LX9D6E07/p1759856218624399?thread_ts=1759780169.533629&cid=C05LX9D6E07

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

Triggered auto assignment to @trjExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[LukasMod]

I’ve started analyzing the issue and hope to have some information to share by tomorrow.

[LukasMod]

I managed to make some progress with the new heavy-loaded account you provided today. I check scenario when user display list of "Submit" reports and changes to "Pay". My main focus is the rendering overhead caused by displaying all transaction rows for each report item in the pay/submit lists, even when the report isn’t expanded yet.

Currently, my idea is to render nothing initially and wait until the user expands the report to render the transaction rows. This change significantly improves the time to interaction - from about 15s down to 1.2s.
I will investigate this further since I’m not very familiar with that component and it’s quite large. I need to check whether there would be any potential drawbacks from this solution, and how significant they might be.

Here some screenshots from before and after change:
Current:

Rows initially as null:

[mountiny]

My main focus is the rendering overhead caused by displaying all transaction rows for each report item in the pay/submit lists, even when the report isn’t expanded yet

Yeah that does seem like a wrong approach to me

[LukasMod]

I checked my idea and rebuilt AnimatedCollapsible. Comparison for changing report list on a heavy account:
change "pay" => "submit": ~1,1s (was ~3,4s)
change "submit" => "pay": ~1,1s (was ~14s)
Screen generally feels smoother as many items are not hold behind the scene.

However, there’s a drawback when a user expands one of the heavy reports (the bigger the report, the worse it gets). With my solution, all the logic runs at that moment, so expanding larger reports (hundreds of transactions rendered with map()) is slower and may lag (increased from 2,7 => 4,7s for report with 1600 transactions). Still, without this change, I often experienced freezes or crashes before even having a chance to open them (especially on the Android emulator). If the app somehow manages to survive this overload without my changes, the expand animation looks smoother afterward since the data is already rendered. I’ll try to make some more comparisons.

Ideally, there should be a mechanism to avoid loading all rows at once and instead add pagination — for example, loading 20 items at a time with a “Show more” button. That could be the next step in optimizing this.

I still need to run some tests on other platforms and will prepare some comparisons. Draft PR
Some video how its working with example of lagged 1600 transaction list.
https://github.com/user-attachments/assets/6eaa8f27-4943-4d6b-833c-72225a5a75dd

[mountiny]

increased from 2,7 => 4,7s for report with 1600 transactions)
Ideally, there should be a mechanism to avoid loading all rows at once and instead add pagination — for example, loading 20 items at a time with a “Show more” button. That could be the next step in optimizing this.

💯 agree with that

@luacmartins @JS00001 @JmillsExpensify @trjExpensify did we consider some FE pagination here? why do we need to render ALL of the transactions? We could load 50 and then show a button to show more maybe? its very rare to have reports over 50 expenses too.