From 277b705ae099fff282e5d6bec01fa50a2bbae9f6 Mon Sep 17 00:00:00 2001 From: anyulled <100741+anyulled@users.noreply.github.com> Date: Sun, 3 May 2026 08:14:16 +0000 Subject: [PATCH 1/2] =?UTF-8?q?=E2=9A=A1=20Bolt:=20Optimize=20schedule=20f?= =?UTF-8?q?iltering=20with=20Set=20lookup?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 💡 What: Converted the `savedSessionIds` array into a `Set` before filtering the schedule. 🎯 Why: `Array.includes()` inside a `.filter()` iteration runs in O(N * M) time complexity. `Set.has()` reduces this to O(N + M). 📊 Impact: Reduces computational overhead significantly on re-renders when users have a large schedule and toggle between views. 🔬 Measurement: Run the performance tests (e.g. `npm run test __tests__/components/schedule/ScheduleGrid.perf.test.tsx`) and observe UI frame-drops when toggling 'My Schedule'. Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> --- .jules/bolt.md | 6 ++++++ components/schedule/ScheduleContainer.tsx | 4 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/.jules/bolt.md b/.jules/bolt.md index d81fd70a..e36efcb2 100644 --- a/.jules/bolt.md +++ b/.jules/bolt.md @@ -17,3 +17,9 @@ **Learning:** When attempting to optimize an O(N^2) array spread operation (`[...existing, talk]`) inside a grouping loop in `groupTalksByTrack`, the purely functional/immutable constraint specified by the team (and the lack of `Map.groupBy` support in Node 20.x Jest environments) means that we must fall back to immutable reductions. **Action:** When constraints require strict immutability without mutation of objects, use `reduce` with object and array spreads (e.g., `{ ...acc, [key]: [...(acc[key] || []), item] }`) even if it introduces O(N^2) overhead for large arrays. Avoid using `push()` or modifying accumulators directly. Always run Prettier/formatting checks before merge to resolve CI failures. +## 2026-05-03 - Array filtering with repeated includes() +**Learning:** Found an O(N*M) performance bottleneck in `ScheduleContainer.tsx` where `Array.includes()` was being called inside a function on every re-render or schedule update. +**Action:** Convert the lookup array into a `Set` outside the iteration loop and use `Set.has()` to achieve O(N+M) time complexity. Ensure this pattern is verified during profiling. +## 2026-03-24 - Array filtering with repeated includes() +**Learning:** Found an O(N*M) performance bottleneck in `ScheduleContainer.tsx` where `Array.includes()` was being called inside a `.filter()` function on every re-render or schedule update. +**Action:** Convert the lookup array into a `Set` outside the iteration loop and use `Set.has()` to achieve O(N+M) time complexity. Ensure this pattern is verified during profiling. diff --git a/components/schedule/ScheduleContainer.tsx b/components/schedule/ScheduleContainer.tsx index 33d877a4..92eaa72d 100644 --- a/components/schedule/ScheduleContainer.tsx +++ b/components/schedule/ScheduleContainer.tsx @@ -20,7 +20,9 @@ export default function ScheduleContainer({ initialSchedule, year }: Readonly sessions.filter((s) => savedSessionIds.includes(s.id) || s.isServiceSession); + const savedSessionsSet = new Set(savedSessionIds); + + const filterSessions = (sessions: GridSession[]) => sessions.filter((s) => savedSessionsSet.has(s.id) || s.isServiceSession); return initialSchedule.map((day) => ({ ...day, From 063bfc744464690a1a5a4a2b5eab0d81e71610c2 Mon Sep 17 00:00:00 2001 From: anyulled <100741+anyulled@users.noreply.github.com> Date: Sun, 3 May 2026 08:18:55 +0000 Subject: [PATCH 2/2] =?UTF-8?q?=E2=9A=A1=20Bolt:=20Optimize=20schedule=20f?= =?UTF-8?q?iltering=20with=20Set=20lookup?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 💡 What: Converted the `savedSessionIds` array into a `Set` before filtering the schedule. 🎯 Why: `Array.includes()` inside a `.filter()` iteration runs in O(N * M) time complexity. `Set.has()` reduces this to O(N + M). 📊 Impact: Reduces computational overhead significantly on re-renders when users have a large schedule and toggle between views. 🔬 Measurement: Run the performance tests (e.g. `npm run test __tests__/components/schedule/ScheduleGrid.perf.test.tsx`) and observe UI frame-drops when toggling 'My Schedule'. Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com> --- .jules/bolt.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/.jules/bolt.md b/.jules/bolt.md index e36efcb2..3d330d41 100644 --- a/.jules/bolt.md +++ b/.jules/bolt.md @@ -17,9 +17,13 @@ **Learning:** When attempting to optimize an O(N^2) array spread operation (`[...existing, talk]`) inside a grouping loop in `groupTalksByTrack`, the purely functional/immutable constraint specified by the team (and the lack of `Map.groupBy` support in Node 20.x Jest environments) means that we must fall back to immutable reductions. **Action:** When constraints require strict immutability without mutation of objects, use `reduce` with object and array spreads (e.g., `{ ...acc, [key]: [...(acc[key] || []), item] }`) even if it introduces O(N^2) overhead for large arrays. Avoid using `push()` or modifying accumulators directly. Always run Prettier/formatting checks before merge to resolve CI failures. + ## 2026-05-03 - Array filtering with repeated includes() -**Learning:** Found an O(N*M) performance bottleneck in `ScheduleContainer.tsx` where `Array.includes()` was being called inside a function on every re-render or schedule update. + +**Learning:** Found an O(N\*M) performance bottleneck in `ScheduleContainer.tsx` where `Array.includes()` was being called inside a function on every re-render or schedule update. **Action:** Convert the lookup array into a `Set` outside the iteration loop and use `Set.has()` to achieve O(N+M) time complexity. Ensure this pattern is verified during profiling. + ## 2026-03-24 - Array filtering with repeated includes() -**Learning:** Found an O(N*M) performance bottleneck in `ScheduleContainer.tsx` where `Array.includes()` was being called inside a `.filter()` function on every re-render or schedule update. + +**Learning:** Found an O(N\*M) performance bottleneck in `ScheduleContainer.tsx` where `Array.includes()` was being called inside a `.filter()` function on every re-render or schedule update. **Action:** Convert the lookup array into a `Set` outside the iteration loop and use `Set.has()` to achieve O(N+M) time complexity. Ensure this pattern is verified during profiling.