[Metrics] Investigate remaining ~1-2s ManualSendMessage spans

[cristipaval]

Context

After cancelling the skeleton-blocked spans, we still see many ManualSendMessage spans in the ~1-2s range. This issue tracks the investigation into which real scenarios are the slowest, so we can target them next.

Ideas to check

1. Concierge chats

Look closer at Concierge chats, or chats that include Concierge responses. Some sessions took longer when the Concierge right panel was used to send messages, or when the user chatted with Concierge directly. Worth checking Concierge-related chats on both mobile and web.

• Sentry example: https://expensify.sentry.io/explore/traces/trace/3d4e34380af84d7e97aa8c67ee73d096/?query=span.op%3AManualSendMessage
• FullStory example: https://fsty.io/v/PwG2JHWS

2. Big account, big report, single expense

Found a user who sent 11 messages, each 2-3s. Worth checking a large account that opens "Spend", then opens a big report with many expenses, then opens a single expense from that list (right side panel) and sends a message there. Many components re-render because of the report + report_action updates.

• FullStory example: https://app.fullstory.com/ui/o-1WN56P-na1/session/1428584047444810677:8703190886144844258

3. Add attributes for the send path

Add attributes that tell us from which path a message was sent. So far the focus was mostly on chat from the inbox. Knowing the path would help us spot the worst scenario faster, and likely unblocks ideas 1 and 2.

Parent

Part of #77176

Issue Owner

Current Issue Owner: @LukasMod

[LukasMod]

Part3:

I opened PR #95666, which adds a new send_message_source attribute on the ManualSendMessage. Goal is to see where people send messages, so we can tell which paths are the send-message bottlenecks instead of looking at one blended number.

To track it, I added a table grouped by this attribute to the Sentry dashboard, giving us a distribution per path (with some variants). With it, we will be able drill into a specific user and see whether certain paths are consistently slower

---

Next, I plan to investigate the 2. Big account, big report, single expense scenario and look for avoidable rerenders.

[cristipaval]

Nice work on the send_message_source attribute and the dashboard table, this will help us a lot to see which paths are the real bottlenecks.

One small thing: I moved this attribute work into its own issue #95709 and repointed PR #95666 there, so the PR closes something scoped. Let's keep this issue (#95584) as the tracking one for the whole investigation.

+1 on going after the 2. Big account, big report, single expense scenario next. The many re-renders from the report + report_action updates look like the main cost there.

[LukasMod]

When a user opens the RHP for a specific transaction and sends a message, the heavy lists rerenders.

The rerenders:

1. Spend results (Search)
2. RHP with transactions and chat, and finally
3. currently opened report

... so its quite a lot of elements, and its only my small test account for sending messages

I'm still experimenting, but even after enabling the React Compiler in MoneyRequestReportTransactionList and stabilizing a few things around it, I haven't seen a consistent improvement so far. Many utilities, hooks, and components rely on the full report or reportActions objects, or on related derived values, so they still have to re-render. I'm trying to pass primitive values instead of whole objects where possible and split some logic to make it more suitable for the React Compiler.

I'll continue investigating this next week.

[LukasMod]

Work in progress, sharing where I've landed so far.

I ran a few experiments. First I measured the span in a scenario where the heavy lists underneath are absent (hidden via a dev toggle), and it came out almost 50% faster. So that's effectively the ceiling for this re-render issue.

From there I tried to stabilize the expensive listing as much as possible using an isFocused-gated freeze, React Compiler, and manual memo where the compiler bails. With several small moves stacked together I got roughly -20% to -25% (stabilizing only MoneyRequestReport now)

Next I'll turn these PoC into a plan with achievable, shippable steps, but I need to to some additional testing.

Metric	Baseline	Ceiling (heavy lists hidden)	Current (stabilizing MoneyRequestReport)
Mean	280.5 ms	159.2 ms	209.8 ms (-25%)

• Baseline = report view renders normally, no optimization.
• Ceiling (heavy lists hidden) = MoneyRequestReportTransactionList and SearchPageWide removed via the dev toggle. Not a shippable implementation (the lists are simply absent).
• Current = the focus-gated freeze plus memo() boundaries, with the lists still fully rendered.

PoC (middle section memoized)

[LukasMod]

The solution seems to be working, but it feels a bit hacky and more like a workaround than a fix for the root cause of the problem - the Onyx subscription call. I'm investigating the subscribed option in the internal useOnyx hook. It would allow us to pause subscriptions on unfocused screens. So far, the initial results look promising. I'm going to do some more testing around this idea, and if it proves to be safe, I'll prepare a proposal for a new Onyx feature:

WIP PoC:
Draft EApp PR: #95952
Draft Onyx PR: Expensify/react-native-onyx#808

Summary

Metric	Baseline	fix	% Change
Samples (n)	27	31	—
Mean	315.0	199.5	−36.7%
Std dev	95.9	45.8	−52.2%
p75	386	238	−38.3%

[LukasMod]

Update: Work in progress. I'm testing different ideas and incorporating some initial feedback before creating the proposal.

[cristipaval]

Thanks for the detailed updates @LukasMod, this is great progress. The Onyx subscribed approach sounds much cleaner than the freeze workaround, and the numbers are promising (−36.7% mean is a big win).

Pausing subscriptions on unfocused screens feels like a good direction for the root cause. Tag me when you post the proposal, and let me know how I can help move it forward.

[LukasMod]

@cristipaval
Sure! I've shared the proposal internally and I'm waiting on feedback now.

The potential gains look great. Today I experimented further with more aggressive changes and stabilized the list in Spend and, in a heavy scenario, spans dropped by almost 70% 🔥, so there's a lot to gain here, though it also involves a fair number of changes. If this gets approved, I think we should roll it out gradually so we can catch any regressions early.
The feature only pays off once the lists are stable through their other render drivers too, and that adds a bunch of conditions / isFocused checks along the way, together with the standard memoization work. Also, for the first use, we should probably do an AdHoc build and have someone else test it too.

I will update when I get some feedback on Monday 👍