fork of https://github.com/sourcegraph/zoekt
matchtree: always use evalMatchTree (#698)
From reading the implementation recently I noticed that we should always
go via evalMatchTree to ensure we correctly use the known map for
caching. This updates the two call sites we didn't do this as well as
documenting this requirement.
I don't think this caused any noticeable performance issues. We would do
slightly more work in the case the root matchTree was an and, but it
would have been miniscule.
Test Plan: go test
author
Keegan Carruthers-Smith
committer
GitHub
date
(Nov 17, 2023, 3:48 PM +0200)
commit
c02b6e0f
c02b6e0f523a52a07f4d32ae8222e18f4ee952e9
parent
88017475
8801747561381ac59c6e5fc246b6991898692f49
+11
-4
+1
-1
eval.go
+1
-1
eval.go
···
291
291
md := d.repoMetaData[d.repos[nextDoc]]
292
292
293
293
for cost := costMin; cost <= costMax; cost++ {
294
-
switch mt.matches(cp, cost, known) {
294
+
switch evalMatchTree(cp, cost, known, mt) {
295
295
case matchesRequiresHigherCost:
296
296
if cost == costMax {
297
297
log.Panicf("did not decide. Repo %s, doc %d, known %v",
+10
-3
matchtree.go
+10
-3
matchtree.go
···
118
118
type matchTree interface {
119
119
docIterator
120
120
121
-
// matches if cost is high enough, caching known values for future
122
-
// evaluation at higher costs. See documentation for matchesState's values.
121
+
// matches if cost is high enough. See documentation for matchesState's
122
+
// values.
123
+
//
124
+
// Note: Do not call this directly, rather use evalMatchTree which uses
125
+
// known to cache responses once the state transitions away from
126
+
// matchesRequiresHigherCost.
123
127
matches(cp *contentProvider, cost int, known map[matchTree]bool) matchesState
124
128
}
125
129
···
615
619
// searches we don't want to run the regex engine if there is no line that
616
620
// contains matches from all terms.
617
621
func (t *andLineMatchTree) matches(cp *contentProvider, cost int, known map[matchTree]bool) matchesState {
618
-
if state := t.andMatchTree.matches(cp, cost, known); state != matchesFound {
622
+
if state := evalMatchTree(cp, cost, known, &t.andMatchTree); state != matchesFound {
619
623
return state
620
624
}
621
625
···
839
843
return cms
840
844
}
841
845
846
+
// evalMatchTree should be called instead of directly calling
847
+
// matchTree.matches. It cache known values for future evaluation at higher
848
+
// costs.
842
849
func evalMatchTree(cp *contentProvider, cost int, known map[matchTree]bool, mt matchTree) matchesState {
843
850
if v, ok := known[mt]; ok {
844
851
return matchesStatePred(v)