Good question, I don't have a good intuition for how much comes from SIMD vs. the rest. I could run benchmarks by disabling SIMD instructions.

This is the case here: filtered term queries get a slowdown but they are still pretty fast, while harder queries like OrHighHigh (top-level disjunctive query) or FilteredOrHighHigh (likewise but with a filter) get faster.

In case you wonder how Lucene decides whether a change is good when there is a mix of speedups and slowdowns, the general rule is that it's better to make the slow queries faster and the fast queries slower than the other way around as this results in lower tail latencies.

Here's the PR: github.com/apache/lucen...

A: The "if score >= minRequiredScore" branch is hard to predict, so this loop is expensive. This small refactoring helped the JVM take advantage of the cmov (conditional move) instruction and make this code branchless.

We're now further taking advantage of it by amortizing the cost of some operations across many doc IDs github.com/apache/lucen... or better vectorizing/pipelining other operations github.com/apache/lucen.... Expect a new round of query evaluation speedups in 10.3.

Thank you Alex

Not that I know of. But we need this kind of benchmark indeed.