[Due for payment 2026-03-18][$250] [Performance] Optimize getSubmitToAccountID (~21ms per render)

[luacmartins]

Problem

getSubmitToAccountID takes ~21ms per render (one of the heaviest in the list) and contributes to slow Reports page navigation.

Solution

Optimize the function (e.g. memoization, caching, or reducing work per call). Use React Profiler / Chrome DevTools to validate improvements.

Issue Owner

Current Issue Owner: @CortneyOfstad

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022024628733439360266
• Upwork Job ID: 2024628733439360266
• Last Price Increase: 2026-02-19

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @bernhardoj (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022024628733439360266

[imgyf]

Proposal

Please re-state the problem that we are trying to solve in this issue.

getSubmitToAccountID takes ~21ms per render, slowing down Reports page navigation. It is called from multiple UI-critical paths (ReportPreviewActionUtils, ReportPrimaryActionUtils, SearchUIUtils, OptionsListUtils), so the cost multiplies across the page.

What is the root cause of that problem?

The bottleneck is inside getRuleApprovers() (called by getSubmitToAccountID at PolicyUtils.ts:1036). Every invocation:

1. Calls getAllSortedTransactions(reportID) which fetches all report transactions via getReportTransactions() and re-sorts them by created/inserted — this allocation + sort happens on every single call, even when the underlying data has not changed.
2. Iterates over every transaction calling getCategory(), getTag(), getCategoryApproverRule(), and getTagApproverRule() to build the approvers list.

Since nothing is memoized or cached, the same expensive work repeats identically each render for the same report/policy combination.

What changes do you think we should make in order to solve the problem?

Memoize getRuleApprovers so repeated calls with the same policy and expenseReport return a cached result instead of re-fetching, re-sorting, and re-iterating transactions.

Concretely in src/libs/PolicyUtils.ts:

1. Extract stable cache keys from the inputs — expenseReport?.reportID and a reference to policy?.rules?.approvalRules (plus the policy employee list, since tag approvers depend on it).
2. Use a lightweight memoization approach (e.g. a module-level cache with shallow equality on the key inputs, similar to patterns already used in the codebase like memoize from lodash or a simple last-result cache) so that getRuleApprovers returns the previous result when called with the same policy rules and report.
3. This automatically makes getSubmitToAccountID fast on subsequent renders since it is a thin wrapper around getRuleApprovers + getManagerAccountID.

This avoids the redundant getAllSortedTransactions sort on every call, which is the most expensive part of the 21ms.

What alternative solutions did you explore? (Optional)

• Memoizing at call sites (useMemo in components): This would work per-component but getSubmitToAccountID is called from many different utility files (not just React components), so memoizing at the source function level is more effective and avoids scattering memoization across 6+ call sites.
• Memoizing getAllSortedTransactions itself: Would help, but is a broader change since that function is used in many other contexts. Memoizing getRuleApprovers is more targeted and lower-risk.

[mas7]

Proposal

Please re-state the problem that we are trying to solve in this issue.

`getSubmitToAccountID` takes ~21ms per call and is invoked 7+ times during render across ReportUtils and OptionsListUtils, creating redundant expensive computation on every Onyx-triggered re-render.

What is the root cause of that problem?

Every call to `getSubmitToAccountID` chains through `getRuleApprovers`, which calls `getAllSortedTransactions(reportID)` — sorting all transactions for the report — then iterates every transaction to check category/tag approver rules via `getCategoryApproverRule` and `getTagApproverRule`. Since this is a plain function (not a hook), there is no memoization between calls within the same render cycle.

When multiple components call `getSubmitToAccountID` with the same `(policy, expenseReport)` pair during a single render, the identical sort + iterate + lookup chain runs from scratch each time.

https://github.com/Expensify/App/blob/main/src/libs/PolicyUtils.ts#L988-L1050

What changes do you think we should make in order to solve the problem?

Add a module-level memoization cache to `getSubmitToAccountID` keyed by `(policyID, reportID)`, invalidated when either input changes. Two approaches, in order of preference:

Approach A — Call-site memoization (preferred):

At each React call site that invokes `getSubmitToAccountID`, wrap the call in `useMemo`:

```typescript
const submitToAccountID = useMemo(
() => getSubmitToAccountID(policy, expenseReport),
[policy, expenseReport],
);
```

This avoids 7+ redundant calls per render while keeping the function pure.

Approach B — Module-level cache (if call sites are too dispersed):

Add a simple WeakMap-based cache inside PolicyUtils using the report object as key:

```typescript
const submitToCache = new WeakMap<object, number>();
function getSubmitToAccountID(policy, expenseReport) {
if (expenseReport && submitToCache.has(expenseReport)) {
return submitToCache.get(expenseReport)!;
}
// ... existing logic ...
if (expenseReport) submitToCache.set(expenseReport, result);
return result;
}
```

WeakMap ensures automatic GC when the report object is no longer referenced.

I will audit all 7+ call sites, apply the appropriate approach per site, and validate with React Profiler to confirm the ~21ms reduction per render.

[melvin-bot]

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