Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This was introduced six months ago in 301fd66 ("Fix off-by-one error in memoization indexing"). It basically meant that you could repeat any matching character and it would be considered to match, as long as your query string didn't exceed the available space in the haystack. For example, given a file "foobar", the following query strings would all match it: "foo", "fooo", "foooo", "fooooo", "fffbar" etc; but strings such as "ffffbar" and "foooooo" would not (due to being overlength). This is the most egregious bug in the matcher ever, so I'm very grateful to Pavel Sergeev (@dzhioev) for reporting it. Alas, the fix comes with a price; while the fix brings a marginal performance increase for most of our test cases, the "pathological" benchmark gets distinctly slower: Before: user system total real pathological 0.010000 0.000000 0.010000 ( 0.003380) command-t 0.410000 0.000000 0.410000 ( 0.413851) chromium (subset) 1.190000 0.010000 1.200000 ( 0.552776) chromium (whole) 4.540000 0.010000 4.550000 ( 1.557351) After: user system total real pathological 1.750000 0.000000 1.750000 ( 1.751254) command-t 0.380000 0.000000 0.380000 ( 0.375418) chromium (subset) 1.170000 0.010000 1.180000 ( 0.498126) chromium (whole) 4.470000 0.010000 4.480000 ( 1.537441) This reverses the win reported in 301fd66, which at the time I described as "so marked that I am almost suspicious of it". I should have been more suspicious... I'll keep digging into this to see if I can improve the speed of the pathological case, but for now I just want to get this fix out as correctness is more important than speed. Fixes: #82 Signed-off-by: Greg Hurrell <greg@hurrell.net>
- Loading branch information