Skip to content

⚡ Bolt: Optimize bitflag early-exit in hot loop#485

Merged
AhmmedSamier merged 3 commits into
masterfrom
bolt-opt-bitflag-13368785946498136939
Jun 1, 2026
Merged

⚡ Bolt: Optimize bitflag early-exit in hot loop#485
AhmmedSamier merged 3 commits into
masterfrom
bolt-opt-bitflag-13368785946498136939

Conversation

@AhmmedSamier

@AhmmedSamier AhmmedSamier commented Jun 1, 2026

Copy link
Copy Markdown
Owner

💡 What: Moved the bitflag early-exit check to the very top of the processItemForSearch hot loop method.
🎯 Why: Previously, the early exit was inside the calculateSearchScore method, which means for non-matching items, we still incurred the cost of variable lookups (context.itemTypeIds[i]), assignments, and a function call before discarding them. Moving it to the caller skips all of this overhead.
📊 Impact: Expected to reduce processing time in the core indexing and search routines for large workspaces by instantly discarding incompatible items with lower CPU overhead.
🔬 Measurement: Verify using run_benchmarks.sh. Specifically, the time for Endpoint Search (Unified) and Fuzzy Search 'File100' should decrease.


PR created automatically by Jules for task 13368785946498136939 started by @AhmmedSamier

Summary by CodeRabbit

  • Documentation

    • Added release notes documenting recommended optimization patterns for search performance in demanding scenarios.
  • Refactor

    • Optimized search engine by reorganizing how candidate filtering conditions are evaluated, moving early-exit checks before intensive processing to reduce unnecessary function calls, improving throughput and responsiveness during search operations.

Moved the bitflag early-exit check to the very beginning of the processItemForSearch method to avoid overhead of function calls and variable assignments for items that don't match.

Co-authored-by: AhmmedSamier <17784876+AhmmedSamier@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

coderabbitai Bot commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@AhmmedSamier, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 35 minutes and 18 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, 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 include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 5c037ec5-e417-4c31-8ed8-8bd74b3b280d

📥 Commits

Reviewing files that changed from the base of the PR and between f500c9e and fa67d06.

📒 Files selected for processing (1)
  • .jules/bolt.md
📝 Walkthrough

Walkthrough

Bitflag-based candidate filtering is relocated from calculateSearchScore helper into processItemForSearch loop as an early-exit check, and a changelog note documents the optimization pattern of moving O(N) early-exit conditions to the loop caller to avoid per-item function calls.

Changes

Search Engine Bitflag Pruning Optimization

Layer / File(s) Summary
Bitflag early-exit in search hot path
language-server/src/core/search-engine.ts, .jules/bolt.md
Bitflag pruning check (itemBitflags vs queryBitflags) is moved from calculateSearchScore into processItemForSearch as an early-exit fast path, and a changelog entry documents this pattern for relocating per-item loop guards to skip helper function calls entirely.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

  • AhmmedSamier/DeepLens#451: Also modifies search-engine.ts to move the bitflag/Bloom-filter early-exit pruning earlier in the search loop from calculateSearchScore into per-item processing.
  • AhmmedSamier/DeepLens#453: Also applies the same queryBitflags/itemBitflags pruning as an early O(1) fast-path inside the item-scanning loop instead of deeper in the scoring pipeline.
  • AhmmedSamier/DeepLens#256: Implements the same bitflag-based candidate pruning logic in search-engine.ts but relocates it from inside calculateSearchScore into processItemForSearch.

Poem

🐰 A hop, a check, a quick return—
Skip the work when bits don't burn!
From helper depths to loop's first gate,
Early exits make searches great! ✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: moving a bitflag early-exit optimization from within a function to the top of the hot loop in processItemForSearch.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch bolt-opt-bitflag-13368785946498136939

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.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f500c9e5d9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +1895 to +1896
if ((context.itemBitflags[i] & context.queryBitflags) !== context.queryBitflags) {
return;

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Don't prefilter endpoint route matches by template bitflags

For concrete endpoint queries with route parameters, this early return can drop valid matches before tryUrlEndpointMatch runs. RouteMatcher.scoreMatchPattern is designed to match arbitrary parameter values (e.g. api/customers/5 against api/customers/{id}), but the item bitflags are computed from the route template/name/path, so a query containing a digit or parameter value characters absent from the template fails this check and the endpoint is never considered. Previously the fuzzy score could be -Infinity while URL matching still rescued the result; keep URL endpoint matching outside this bitflag prefilter or exempt potential URL endpoint searches.

Useful? React with 👍 / 👎.

…ighlights tracking

Resolved merge conflict by combining the bitflag early-exit check from HEAD (bolt-opt-bitflag-13368785946498136939) with the currentHighlights reset from master. The bitflag check is now performed first to quickly eliminate non-matching items before resetting the currentHighlights context variable. Also resolved the .jules/bolt.md conflict by merging all innovation entries from both branches.
The bitflag early-exit check at the start of processItemForSearch was redundant since it was immediately followed by another check that respected shouldPreserveEndpointRouteMatch. Removing the first check ensures endpoint route matching can work properly for queries containing characters (like digits) not present in the route template.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant