Coming from here
Background
If a report has a violation (e.g., a failed receipt scan), we mark it with RBR in the LHN. To indicate that action is required, RBR also appears in the Workspace Switcher next to the policy containing the report and in the bottom tabs alongside the Inbox item.
Problem
The logic for determining whether to display RBR in the LHN and Inbox tab is inefficient, consuming excessive CPU resources and slowing down the rendering process. The function getOrderedReportIds, previously identified as slow for accounts with a large number of reports, is significantly impacted. Performance results for an account with 15k reports on web:
getOrderedReportIDs takes 1.35s, delaying LHN rendering.getBrickRoadForPolicy takes 392ms, affecting the Inbox tab in the bottom navigation.
The issue is caused by shouldDisplayViolationsRBRInLHN , which is being inefficient when handling large amounts of reports and policies - it took 1.63s in total.
Solution
Refactor shouldDisplayViolationsRBRInLHN to eliminate redundant computations. Instead of iterating through all reports within the function on every call, build a precomputed map of reports by policyID. This enables quick lookups and significantly reduces processing time. Performance gains after optimization:
getOrderedReportIDs: 435ms (-900ms)getBrickRoadForPolicy: 3ms (-389ms)shouldDisplayViolationsRBRInLHN: 10ms (-1.63s)
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~021889571854486041914
- Upwork Job ID: 1889571854486041914
- Last Price Increase: 2025-02-12
Issue Owner
Current Issue Owner: @TMisiukiewicz
Coming from here
Background
If a report has a violation (e.g., a failed receipt scan), we mark it with RBR in the LHN. To indicate that action is required, RBR also appears in the Workspace Switcher next to the policy containing the report and in the bottom tabs alongside the Inbox item.
Problem
The logic for determining whether to display RBR in the LHN and Inbox tab is inefficient, consuming excessive CPU resources and slowing down the rendering process. The function getOrderedReportIds, previously identified as slow for accounts with a large number of reports, is significantly impacted. Performance results for an account with 15k reports on web:
getOrderedReportIDstakes 1.35s, delaying LHN rendering.getBrickRoadForPolicytakes 392ms, affecting the Inbox tab in the bottom navigation.The issue is caused by
shouldDisplayViolationsRBRInLHN, which is being inefficient when handling large amounts of reports and policies - it took 1.63s in total.Solution
Refactor
shouldDisplayViolationsRBRInLHNto eliminate redundant computations. Instead of iterating through all reports within the function on every call, build a precomputed map of reports by policyID. This enables quick lookups and significantly reduces processing time. Performance gains after optimization:getOrderedReportIDs: 435ms (-900ms)getBrickRoadForPolicy: 3ms (-389ms)shouldDisplayViolationsRBRInLHN: 10ms (-1.63s)Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @TMisiukiewicz