perf(search): evaluate in-place intersection and explicit score loop

[seonghobae]

Current authority

• protected/base: main@47c6fd27de13b0da37a7db64697b869941909351
• exact head: 572f8e8b9aa8f73184f9ab73d92472730fdac7f3
• lifecycle: Draft / open / mergeable
• effective diff: transcript_search.py only (+10/-4)

Scope correction

The generated candidate contains two independent Python micro-optimizations:

1. keep the initial defensive set(postings) working copy, then use intersection_update(postings) instead of allocating a new set on each later term;
2. replace sum(entry.counts[term] for term in unique_terms) with an explicit accumulator loop using one local counts binding.

The generated .jules/bolt.md asserted both choices as universally faster and quoted an expected ~30% improvement without repository-current representative evidence. That retrospective doctrine has been removed ordinary-forward by restoring the protected blob byte-for-byte; the generated commits remain in ancestry.

This PR is an alternative candidate to #622, not proven superior to it. #622 currently evaluates the same in-place intersection plus a list-comprehension score reduction; this head instead uses an explicit accumulator loop and avoids that list allocation. Choose between the score implementations only from enclosing TranscriptIndex.search() measurements, not intuition or isolated-expression timing.

Required semantic RED/GREEN

Before performance promotion, add executable equivalence against protected behavior covering empty/missing postings, one-term and repeated-term queries, early/late empty intersections, score/tie ordering, skewed/large postings, Unicode/CJK, and explicit proof that self._postings is never mutated. The resulting Match values and ordering must be identical.

Performance acceptance

Measure the actual search path on the same runtime/host with a documented right-cleared workload shape (entries, postings cardinality/skew, terms, match count), warm-up/repetition policy, wall/CPU median+p95, allocation and peak-memory evidence. Separate the intersection and score-loop effects through ablation. Do not claim ~30% or buyer-visible benefit unless the enclosing path demonstrates it beyond noise.

The new exact head has no PR workflow runs visible yet; predecessor results do not transfer. Keep Draft until one unchanged exact head has semantic equivalence, measured evidence appropriate to the claim, terminal required gates, and qualifying independent review.

No force push, destructive rebase, self-approval, source-neutral rerun, scanner suppression, gate weakening, or predecessor-GREEN transfer.

[google-labs-jules]

👋 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]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}