[Due for payment 2026-02-23] Use Derived Values for Report Name Computation in OptionsListUtils #78786
Description
Coming from https://expensify.slack.com/archives/C05LX9D6E07/p1767102253351349
Strategy
Improving UI responsiveness and reducing battery consumption is critical for power users who manage hundreds of reports.
Background
OptionsListUtils generates searchable lists for the LHN, Search, and Participant Pickers. It relies on computeReportName(), a utility that:
- Parses 7 data collections and 10+ report types.
- Executes complex string formatting and localization.
- Runs on every render cycle during sidebar scrolling and search filtering.
Problem
When OptionsListUtils functions execute during list generation, if the application renders the sidebar or filters search results, then redundant calls to computeReportName() consume excessive CPU cycles, causing UI junks and battery drain on mobile devices.
Solution
Replace direct utility calls (computeReportName) with cached lookups from ONYXKEYS.DERIVED.REPORT_ATTRIBUTES.
The ONYXKEYS.DERIVED.REPORT_ATTRIBUTES values are automatically computed and kept in sync by a central derived value system, which caches expensive report properties (like names) whenever the underlying report or personal detail data changes.
This maintains backward compatibility and requires zero changes to the public API or the derived value logic itself.
Testing a search filter operation showed significant improvement, before changes a single search executed 133 calls to computeReportName function, after changes it called 39 times.
Impact - 70% reduction in redundant operations
Notes
This proposal is a follow-up to a discussion in a previously merged PR (link: #74071 (comment))
Issue Owner
Current Issue Owner: @kadiealexanderMetadata
Metadata
Labels
Type
Projects
Status