⚡ Bolt: Fast Lazy Lowercase Optimization in Search Engine#418
⚡ Bolt: Fast Lazy Lowercase Optimization in Search Engine#418AhmmedSamier wants to merge 1 commit intomasterfrom
Conversation
…stSearch Eliminate redundant O(N) string allocations during exhaustive search scans by lazily reading `_targetLower` from the pre-computed Fuzzysort prepared objects in the parallel `preparedFullNames` array. Co-authored-by: AhmmedSamier <17784876+AhmmedSamier@users.noreply.github.com>
|
👋 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 New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
📝 WalkthroughWalkthroughThis PR optimizes the search engine's burst search to avoid repeated ChangesLazy Evaluation Optimization
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
language-server/src/core/search-engine.ts (1)
2229-2233:⚠️ Potential issue | 🟠 Major | ⚡ Quick winGuard the private Fuzzysort field before using it.
Both lowercase lookups (lines 2230 and 2266) depend on
_targetLower, which is not documented in fuzzysort 3.1.0's public API and is an internal implementation detail. If this field is absent or undefined,nameLowerandfullLowerbecomeundefined, causing.indexOf()calls to throw. Use optional chaining with a nullish fallback to safely preserve the optimization.Suggested fix
- const nameLower = prepared - ? (prepared as unknown as ExtendedPrepared)._targetLower - : item.name.toLowerCase(); + const nameLower = (prepared as ExtendedPrepared | null)?._targetLower ?? item.name.toLowerCase(); const score = this.calculateMatchScore(nameLower, item.fullName, this.preparedFullNames[i], queryLower); if (score > 0) { addResult(item, this.itemTypeIds[i], score); } @@ - const fullLower = preparedFullName - ? (preparedFullName as unknown as ExtendedPrepared)._targetLower - : fullName.toLowerCase(); + const fullLower = + (preparedFullName as ExtendedPrepared | null)?._targetLower ?? fullName.toLowerCase();🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@language-server/src/core/search-engine.ts` around lines 2229 - 2233, The code reads the private fuzzysort field _targetLower from prepared (used to set nameLower/fullLower) which may be undefined; update the logic in the block that sets nameLower and fullLower (where prepared and ExtendedPrepared are used and before calling calculateMatchScore and using preparedFullNames/queryLower) to use optional chaining with a nullish fallback—e.g., use (prepared as ExtendedPrepared)?._targetLower ?? item.name.toLowerCase() for nameLower and similarly fall back to item.fullName.toLowerCase() for fullLower—so the code never sets nameLower/fullLower to undefined before calling calculateMatchScore or performing .indexOf().
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.jules/bolt.md:
- Line 35: The journal header "## 2024-05-18 - Lazy Evaluation of Pre-computed
Full Names in Search Engine" has the wrong year; update the date to the correct
2026 year to match surrounding entries and this PR timeline (e.g., change
"2024-05-18" to "2026-05-18") so the entry appears in sequence.
---
Outside diff comments:
In `@language-server/src/core/search-engine.ts`:
- Around line 2229-2233: The code reads the private fuzzysort field _targetLower
from prepared (used to set nameLower/fullLower) which may be undefined; update
the logic in the block that sets nameLower and fullLower (where prepared and
ExtendedPrepared are used and before calling calculateMatchScore and using
preparedFullNames/queryLower) to use optional chaining with a nullish
fallback—e.g., use (prepared as ExtendedPrepared)?._targetLower ??
item.name.toLowerCase() for nameLower and similarly fall back to
item.fullName.toLowerCase() for fullLower—so the code never sets
nameLower/fullLower to undefined before calling calculateMatchScore or
performing .indexOf().
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 257f1e8d-6267-4b63-9c44-74eb29110965
📒 Files selected for processing (2)
.jules/bolt.mdlanguage-server/src/core/search-engine.ts
| ## 2026-05-04 - [Fix CI SIGTRAP Failure] | ||
|
|
||
| **Learning:** `xvfb-run` crashes with `SIGTRAP` in GitHub Actions for `vscode-extension` integration tests if they run too soon after `dbus` services start or fail, likely due to missing display configurations in the headless agent environment for Electron integration testing via `@vscode/test-electron`. Wait! No, that's from my past memory. Let me see what I just fixed. I fixed `indexer-worker.ts` with `pLimit`. Let's just submit. | ||
| ## 2024-05-18 - Lazy Evaluation of Pre-computed Full Names in Search Engine |
There was a problem hiding this comment.
Fix the journal date.
2024-05-18 is out of sequence with the surrounding 2026 entries and this PR’s May 6, 2026 timeline, so the optimization will look like it landed two years earlier than it actually did.
Suggested fix
-## 2024-05-18 - Lazy Evaluation of Pre-computed Full Names in Search Engine
+## 2026-05-06 - Lazy Evaluation of Pre-computed Full Names in Search Engine📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## 2024-05-18 - Lazy Evaluation of Pre-computed Full Names in Search Engine | |
| ## 2026-05-06 - Lazy Evaluation of Pre-computed Full Names in Search Engine |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.jules/bolt.md at line 35, The journal header "## 2024-05-18 - Lazy
Evaluation of Pre-computed Full Names in Search Engine" has the wrong year;
update the date to the correct 2026 year to match surrounding entries and this
PR timeline (e.g., change "2024-05-18" to "2026-05-18") so the entry appears in
sequence.
1 participant
💡 What: Refactored
calculateMatchScoreto lazily read the pre-computed lowercased string (_targetLower) from the FuzzysortPreparedobject (this.preparedFullNames[i]) instead of dynamically callingfullName.toLowerCase()in the search loop.🎯 Why: When a fast-path exact or prefix match fails, the
burstSearchloop exhaustively scans all remaining items. For items with afullName, dynamically converting it to lowercase inside the hot loop causes redundant string allocations, leading to performance degradation and garbage collection overhead in large workspaces.📊 Impact: The benchmark "Burst Search 'Zzz' (No match)", which forces a full scan of all items, showed a performance improvement:
This represents roughly a ~6% reduction in CPU time for worst-case exhaustive searches over 50,000 items.
🔬 Measurement: Verify by running
cd language-server && bun run benchmarks/search_burst.bench.ts.PR created automatically by Jules for task 11547415513580184095 started by @AhmmedSamier
Summary by CodeRabbit