[HOLD for payment 2025-01-15] [HOLD for payment 2024-12-25] Benchmark performance bottlenecks when opening chats

[adhorodyski]

Coming from the discussion thread under https://expensify.slack.com/archives/C05LX9D6E07/p1728314452317409

Problem

Lack of solid performance benchmarks across the core app workflows, baselines for proposing performance improvements.

Solution

• Focus on 1 scenario of opening a chat
• Benchmark it in detail to get the granular results (also for each phase) so we have solid numbers for whom specifically it's slow and why. There are also analytics we can use for this to have more datapoints.
• Pinpoint the areas for improvement we see
• Map how the proposal from initial thread/nitro modules/anything other can fit to improve it

cc @hannojg

Issue Owner

Current Issue Owner: @laurenreidexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021873115691475801087
• Upwork Job ID: 1873115691475801087
• Last Price Increase: 2024-12-28

[adhorodyski]

@mountiny could you please assign this one to me & @hannojg? Thanks!

[hannojg]

Thanks! 👋

[adhorodyski]

Update
Our bottom line is to get super solid on what precisely is slow (have granular measurements) and for whom specifically.

Who
To be able to say how many people something affects (in different percentiles), we need to have something to segment by. We'll extend our performance analytics' metadata (in all envs, including e2e tests) to include the below fields. These will help us group measurements by the types of accounts. (PR: #50881)

• number of reports ✅
• number of reportActions 🔄
• number of personalDetails ✅
• number of policies 🔄
• number of transactions 🔄
• number of transactionViolations 🔄

What
To be able to pinpoint what exactly is slow, we'll implement granular metrics in code, across both App & Onyx. Here's a breakdown of all the phases we decided to focus on.

• APPLYING_UPDATES (coming over https, until we schedule notifying subscribers)
  • DATABASE_WRITE (actual save operations like multiset and multimerge)
• NOTIFYING_SUBSCRIBERS (multiple key(s)Changed triggered by scheduleNotifyCollectionSubscribers)
  • DATABASE_READ
  • REACT_PROVIDER - (useOnyx/withOnyx)
• ONYX_DATA_POSTPROCESSING (from receiving a new update (subscriber got called) until we have the final data)

How
TBC

[adhorodyski]

cc @mountiny we'd like to ask you for any feedback about this 1st batch (please invite others!). Is there an area we're missing? I want to make sure we focus on the right parts when profiling this, the exact tools (like e2e suites) will come next once we fully agree on the who&what.