Skip to content

⚡ Bolt: Optimize schedule filtering to use Set for O(1) lookups#171

Open
anyulled wants to merge 1 commit intomainfrom
bolt/optimize-schedule-filtering-401793108385955748
Open

⚡ Bolt: Optimize schedule filtering to use Set for O(1) lookups#171
anyulled wants to merge 1 commit intomainfrom
bolt/optimize-schedule-filtering-401793108385955748

Conversation

@anyulled
Copy link
Copy Markdown
Owner

💡 What: The optimization implemented
Replaced the Array.includes() check used during the schedule filtering process in ScheduleContainer.tsx with a Set.has() lookup.

🎯 Why: The performance problem it solves
In components/schedule/ScheduleContainer.tsx, the useMemo block used an array .includes() method inside a .filter() function when iterating over savedSessionIds. This resulted in an $O(N \times M)$ time complexity where $N$ is the number of scheduled sessions and $M$ is the number of saved sessions. As the lists of sessions and user-saved sessions grow, filtering operations (e.g. when toggling the "My Schedule" tab) can cause lag on the main thread and janky rendering.

📊 Impact: Expected performance improvement
Converts the check to an amortized $O(1)$ Set.has() lookup, improving overall execution time complexity from $O(N \times M)$ to $O(N + M)$ during filtering, and effectively preventing main thread blocking on heavily saved schedules.

🔬 Measurement: How to verify the improvement

  1. Create a large array of saved sessions in localStorage.
  2. Navigate to the schedule and profile the JavaScript execution using DevTools when toggling "My Schedule" on and off.
  3. Observe the significantly reduced CPU time spent in the filterSessions callback compared to the base branch.

PR created automatically by Jules for task 401793108385955748 started by @anyulled

Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
@google-labs-jules
Copy link
Copy Markdown
Contributor

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Apr 18, 2026

Warning

Rate limit exceeded

@anyulled has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 37 minutes and 59 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 37 minutes and 59 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 09141ff0-479b-4d33-8193-6bcb27b54c12

📥 Commits

Reviewing files that changed from the base of the PR and between aed836a and dc5d891.

📒 Files selected for processing (1)
  • components/schedule/ScheduleContainer.tsx
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch bolt/optimize-schedule-filtering-401793108385955748

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request optimizes session filtering in the ScheduleContainer component by replacing array lookups with a Set for improved performance. The review feedback suggests further enhancing this by memoizing the Set independently to avoid redundant recreations when other useMemo dependencies change.

}

const filterSessions = (sessions: GridSession[]) => sessions.filter((s) => savedSessionIds.includes(s.id) || s.isServiceSession);
const savedSessionSet = new Set(savedSessionIds);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

While creating a Set inside the useMemo is a significant improvement over Array.includes(), the savedSessionSet is currently recreated every time the useMemo re-runs (e.g., if initialSchedule changes while showSavedOnly is true). For even better performance, especially if the number of saved sessions grows very large, consider memoizing the Set independently or providing it directly from the ScheduleContext.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant