Audit parameterized selectors with single-entry caches across `app/selectors` (51 hits, 14 files)

[MajorLift]

Performance audit finding · Severity: Medium (batch) · Effort: Large · Fix risk: Simple per instance · Test safety net: Partial
Owner: per-file CODEOWNERS
Scope: app/selectors/ (51 hits, 14 files)

What is this about?

Parameterized selectors ((_state, arg) => arg input pattern) built with createSelector have a single-entry cache: calls with alternating arguments from different components bust the cache on every call, so the selector recomputes per call site per render despite being "memoized". Sweep results on main (b3e7eb88), hits per file:

• app/selectors/earnController/earn/index.ts (6)
• app/selectors/tokensController.ts (5) — worst instance filed separately: Fix single-entry cache thrashing in selectSingleTokenByAddressAndChainId (O(n) scan per call) #31490
• app/selectors/tokenRatesController.ts (4)
• app/selectors/networkController.ts (4)
• app/selectors/currencyRateController.ts (4)
• app/selectors/smartTransactionsController.ts (3)
• app/selectors/multisrp/index.ts (3)
• app/selectors/transactionController.ts (2)
• app/selectors/tokenSearchDiscoveryDataController.ts (2)
• app/selectors/multichainAccounts/accounts.ts (2)
• app/selectors/assets/assets-list.ts (2)
• app/selectors/accountsController.ts (2) — compound instance filed separately: getMemoizedInternalAccountByAddress runs a deep-equal compare on top of per-argument cache busting #31491
• app/selectors/transactionPayController.ts (1)
• app/selectors/snaps/permissionController.ts (1)

Detection recipe: grep -rn "(_state\|(_," app/selectors --include="*.ts"

Technical Details

Per instance, triage in this order: (1) lookup-map selector — memoize one keyed index, consumers key into it (preferred; removes per-arg caching entirely); (2) factory selector instantiated per call site with useMemo; (3) lruMemoize with maxSize (last resort). Instances called from a single call site with a stable argument are fine — close them as no-op with a note.

Acceptance Criteria

• Each file's hits triaged: fixed (with reference-stability test) or explicitly waived (single stable call site).
• No parameterized selector consumed per-row in a list retains a single-entry cache.

References

• Source: mms-performance sweep recipes added in perf: Augment mms-performance with frontend learnings from the Extension performance audit skills#49 (mm-state-normalization); pattern catalogued in the extension audit as MetaMask-planning#6484
• Status: UNVALIDATED per instance (static sweep; needs per-instance review)

[metamask-ci]

Triage Agent -- Classification

Severity: Sev3 (confidence: 0.88) ✅

This is a performance optimization issue, not a functional bug. The app works correctly but performs unnecessary recomputations due to suboptimal memoization strategies. No data loss, crashes, or security issues. Users may experience slightly degraded performance (slower renders) but the app remains fully functional. This is a code quality/performance improvement task.

Size: size-L (confidence: 0.82) ⚠️ Advisory

The issue identifies 51 instances across 14 files that need to be audited and potentially refactored. Each parameterized selector needs to be evaluated for whether it's called with alternating arguments, and if so, migrated to use weakMapMemoize or re-reselect's createCachedSelector pattern. Some selectors (like selectNetworkConfigurationByChainId) have already been fixed with weakMapMemoize, so the pattern exists, but applying it consistently across 51 instances is substantial work requiring careful testing.
Not auto-applied -- confidence below threshold.

Team: team-mobile-platform ✅

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

---

Root Cause Analysis

Affected component: app/selectors/ - parameterized selectors across multiple controller selector files

Reselect's createSelector uses a single-entry (size-1) LRU cache by default. When a parameterized selector (one that takes extra arguments like chainId, address, etc.) is called from multiple components with different argument values, each call with a new argument evicts the cached result, causing the selector to recompute even though the underlying state hasn't changed. For example, selectNativeCurrencyByChainId, selectDefaultEndpointByChainId, selectTickerByChainId, and checkNetworkAndAccountSupports1559 in networkController.ts all use the (_state, arg) => arg pattern without weakMapMemoize. When Component A calls selectNativeCurrencyByChainId(state, '0x1') and Component B calls it with '0x89', each call invalidates the other's cache entry, causing perpetual recomputation. The fix pattern already exists in the codebase: selectNetworkConfigurationByChainId correctly uses { argsMemoize: weakMapMemoize, memoize: weakMapMemoize } to create an unbounded cache keyed by the argument, but this pattern hasn't been applied consistently.

Evidence:

• selectNativeCurrencyByChainId uses createSelector with (_state, chainId) => chainId but no weakMapMemoize
• selectDefaultEndpointByChainId uses createSelector with (_: RootState, chainId: Hex) => chainId but no weakMapMemoize
• selectTickerByChainId uses createSelector with (_state, chainId: Hex) => chainId but no weakMapMemoize
• checkNetworkAndAccountSupports1559 uses createSelector with (_state, networkClientId: string) => networkClientId but no weakMapMemoize
• selectSmartTransactionsOptInStatus uses (_state, _chainId?) => undefined pattern for type compatibility but still single-entry cache
• selectNetworkConfigurationByChainId already correctly uses { argsMemoize: weakMapMemoize, memoize: weakMapMemoize } - proving the pattern is known
• selectInternalAccountsByScope in accountsController.ts uses createDeepEqualSelector with (_state, scope) => scope but no weakMapMemoize
• getMemoizedInternalAccountByAddress uses createDeepEqualSelector with (_state, address) => address but no weakMapMemoize
• Issue reports 51 instances across 14 files

Suggested Fix

Confidence: high: clear from code context - the fix pattern (weakMapMemoize) already exists in selectNetworkConfigurationByChainId and just needs to be applied consistently to the other parameterized selectors

For each parameterized selector using the (_state, arg) => arg pattern with createSelector or createDeepEqualSelector, add weakMapMemoize configuration to enable multi-entry caching. This prevents cache thrashing when the same selector is called with different arguments from different components.

Target files: app/selectors/networkController.ts, app/selectors/accountsController.ts, app/selectors/preferencesController.ts
Target functions: selectNativeCurrencyByChainId, selectDefaultEndpointByChainId, selectProviderTypeByChainId, selectRpcUrlByChainId, selectTickerByChainId, checkNetworkAndAccountSupports1559, getMemoizedInternalAccountByAddress, selectInternalAccountsByScope, selectSmartTransactionsOptInStatus

Approach:

1. Run grep -rn '(_state\|(_,' app/selectors --include='*.ts' to identify all 51 parameterized selectors.
2. For each identified selector, determine if it's called from multiple components with different arguments (high priority) or only from one call site (lower priority).
3. For high-priority selectors, add { argsMemoize: weakMapMemoize, memoize: weakMapMemoize } as the options argument to createSelector/createDeepEqualSelector. Follow the existing pattern from selectNetworkConfigurationByChainId.
4. Example fix for selectNativeCurrencyByChainId:

   export const selectNativeCurrencyByChainId = createSelector(
     [selectEvmNetworkConfigurationsByChainId, (_state: RootState, chainId) => chainId],
     (networkConfigurations, chainId) => networkConfigurations?.[chainId]?.nativeCurrency,
     { argsMemoize: weakMapMemoize, memoize: weakMapMemoize },
   );

5. For createDeepEqualSelector-based parameterized selectors, ensure the utility supports passing options through, or switch to createSelector with weakMapMemoize (which provides similar benefits since weakMapMemoize uses reference equality on arguments).
6. Ensure weakMapMemoize is imported from 'reselect' in each file.
7. Add unit tests verifying that calling the selector with alternating arguments doesn't cause recomputation when state hasn't changed.

---

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.
⚠️ Some dimensions could not be confidently classified. An engineer should review this issue.