Fix single-entry cache thrashing in `selectSingleTokenByAddressAndChainId` (O(n) scan per call)

[MajorLift]

Performance audit finding · Severity: High · Effort: Medium · Fix risk: Simple · Test safety net: Partial
Owner: @MetaMask/metamask-assets (suggested)
File: app/selectors/tokensController.ts:174

What is this about?

selectSingleTokenByAddressAndChainId is a parameterized createSelector with reselect's default single-entry cache. Every call with a different (tokenAddress, chainId) pair busts the cache of the previous call, and the result function runs an O(n) scan (Object.values(allTokens[chainId] ?? {}).flat() then .find()) on every miss. In a list rendering N rows that each resolve a token, the "memoized" selector recomputes N times per render cycle, forever.

Why it matters

Cost scales with token count × visible rows. For a power-user data profile (~90+ assets) this is a full token-map flatten + linear scan per row per render, on hot asset paths.

Scenario

N/A — see Technical Details.

Design

N/A — internal performance change; no UI/design impact.

Technical Details

Evidence

app/selectors/tokensController.ts:174

export const selectSingleTokenByAddressAndChainId = createSelector(
  getTokensControllerAllTokens,
  (_state: RootState, tokenAddress: Hex) => tokenAddress,
  (_state: RootState, _tokenAddress: Hex, chainId: Hex) => chainId,
  (allTokens, tokenAddress, chainId) => {
    const chainTokens = Object.values(allTokens[chainId] ?? {}).flat();
    return chainTokens.find(
      (token) => token.address.toLowerCase() === tokenAddress.toLowerCase(),
    );
  },
);

Fix

Preferred: a lookup-map selector — memoize one chainId → addressLowercase → Token index that recomputes only when allTokens changes, and have consumers key into it (O(1) per lookup, no per-arg cache to bust). Alternative: a makeSelectSingleTokenByAddressAndChainId() factory instantiated per call site with useMemo, so each call site owns its own cache slot.

Threat Modeling Framework

N/A — performance-only change; behavior is preserved, no new data flow / trust boundary / attack surface.

Acceptance Criteria

• Index selector returns the same reference across two dispatches with unchanged token data (assert with toBe).
• selector.recomputations() (or console.count in the result fn) drops from N-per-render to ~1-per-data-change while scrolling a token list.

References

• File: app/selectors/tokensController.ts:174
• Source: mms-performance sweep recipes added in perf: Augment mms-performance with frontend learnings from the Extension performance audit skills#49 (mm-state-normalization — parameterized-selector cache thrashing); pattern catalogued in the extension audit as MetaMask-planning#6484
• Status: UNVALIDATED (static evidence; needs profiler confirmation)

[metamask-ci]

Triage Agent -- Classification

Severity: Sev2 (confidence: 0.85) ✅

This is a performance issue affecting token list rendering. Each render cycle with N tokens causes N recomputations of an O(n) scan, leading to quadratic behavior. While it doesn't break functionality, it degrades performance noticeably as token count grows, especially on mobile devices. Workaround exists (users can still use the app, just with degraded performance).

Size: size-S (confidence: 0.85) ✅

The fix involves changing a single selector to use a multi-entry cache (e.g., re-reselect's createCachedSelector, or a custom memoization strategy with a Map-based cache keyed by (tokenAddress, chainId)). This is a well-understood pattern with a clear root cause and a single-file fix.

Team: team-assets ✅

Matched via area fallback: area-tokens (no CODEOWNERS match)

---

Root Cause Analysis

Affected component: selectSingleTokenByAddressAndChainId selector (likely in app/selectors/ directory)

The selector selectSingleTokenByAddressAndChainId is a parameterized reselect selector that takes (tokenAddress, chainId) as arguments. Reselect's createSelector uses a default cache size of 1, meaning it only remembers the last set of arguments. When a token list renders N rows, each row calls this selector with a different (tokenAddress, chainId) pair, causing N consecutive cache misses. Each miss triggers the result function which performs an O(n) scan using Object.values().flat().find() over the token map. This results in O(N*n) work per render cycle where N is the number of visible rows and n is the total token count. The token list component (app/components/UI/Tokens/index.tsx) renders via TokenList which iterates over tokenKeysForList, and each TokenListItem likely calls this selector individually.

Evidence:

• Issue explicitly describes O(n) cache thrashing with parameterized selector
• Reselect's default createSelector has cache size of 1
• Object.values().flat().find() pattern described as the result function
• Token list renders multiple rows each calling the selector with different params
• The Tokens component uses selectSortedAssetsBySelectedAccountGroup which provides token keys, and individual items likely use selectSingleTokenByAddressAndChainId for per-token data

Suggested Fix

Confidence: medium: likely but needs investigation - the exact file path for the selector is not in the provided KB context, but the pattern and fix approach are well-established

Replace the single-entry cached reselect selector with a multi-entry cached approach. Options include: (1) Use re-reselect (createCachedSelector) which provides per-key caching, (2) Use createSelector with lruMemoize and a larger cache size, or (3) Create a selector that returns the entire token map and let components do their own lookup (moving the O(1) lookup to the component level). The best approach is likely option (1) or restructuring to use a map-based selector that returns all tokens indexed by (address, chainId) composite key, then having each component do a simple O(1) property access.

Target files: app/selectors/tokenSelectors.ts or similar file containing selectSingleTokenByAddressAndChainId
Target functions: selectSingleTokenByAddressAndChainId

Approach:

1. Locate the selector definition (likely in app/selectors/ - search for 'selectSingleTokenByAddressAndChainId'). 2. Option A: Replace with re-reselect's createCachedSelector, keying the cache on (tokenAddress, chainId) so each unique pair gets its own cached result. 3. Option B: Create a parent selector selectTokensByAddressAndChainId that returns a Map<string, Token> keyed by ${address}-${chainId}, using a single reselect selector (one cache entry for the whole map). Then create a simple lookup function (not a selector) or use the map directly in components. 4. Option C: If using reselect v5+, use createSelector with {memoize: lruMemoize, memoizeOptions: {maxSize: 50}} to increase cache size. 5. Ensure the parent input selector (the token map/list from state) is stable to avoid unnecessary recomputations of the map itself.

---

Confidence threshold: 0.85. Labels marked ✅ were auto-applied. Labels marked ⚠️ are advisory only (below threshold).
To re-triage, remove the ta-bot-triage label and re-apply ta-needs-triage.