blevesearch / bleve / 29585093159

52%

master: 52%

Build Type

Pull #2382

github

Committed by capemox

Commit Message

perf: omit postings-count read for fuzzy/regexp candidate collection

Fuzzy and regexp candidate collection iterate the field dictionary via the
levenshtein/regexp automaton and use only the term and edit distance —
DictEntry.Count is discarded. The segment iterator nonetheless read each
visited term's postings list to compute that count.

Add a termDictionaryOmitCount optional interface (AutomatonIteratorOmitCount)
and use it from the fuzzy and regexp field-dict constructors so the count
(and its per-term postings read) is skipped. This is opt-in per call site:
FieldDict / FieldDictPrefix / FieldDictRange still populate counts, since
faceting and public dictionary APIs rely on them.

The wiring uses a type assertion, so it degrades gracefully: with a zapx
that predates AutomatonIteratorOmitCount it falls back to the count-reading
path (TestFieldDictFuzzyAutomatonOmitsCount, added here, skips in that case).
The optimization activates once the zapx/v17 dependency is bumped to a
release that includes the omit-count iterator.

Benchmark (BenchmarkFuzzyCandidateCollection from the previous commit; scorch
index, 1000 terms / 3000 docs, fuzziness-2 query matching 280 candidates),
parent vs this commit, Apple M4 Pro, count=12 via benchstat:

  sec/op      135.5µ -> 122.4µ   -9.7%   (p=0.000)
  B/op        667.1Ki -> 659.9Ki -1.1%   (p=0.000)
  allocs/op   975 -> 691         -29.1%  (p=0.000)

Combined with the previous commit: -15.0% sec/op, -30.1% allocs/op vs the
original candidate-collection path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Pull Request Pull Request #2382: perf: fuzzy/regexp candidate-collection optimizations

Coverage Stats

12 of 52 new or added lines in 3 files covered. (23.08%)

5 existing lines in 3 files now uncovered.

19845 of 37948 relevant lines covered (52.3%)

0.59 hits per line