iprithv commented on PR #16069: URL: https://github.com/apache/lucene/pull/16069#issuecomment-4479017653
> I don't think we want to guard on specific implementations. Do you know why the general gating on cost implementations isn't working here? For dense filters we should be going via advance anyway, and for sparse filters even a bit-by-bit intoBitSet implementation should be fine. eg compare with DenseConjunctionBulkScorer. Actually when i ran, it wasn’t helping in our benchmarks since we were testing with RandomQuery. for something like RandomQuery(80%), the default intoBitSet ends up iterating a lot of docs, which is slower than just using advance() when the disjunction is sparse. so that’s why I thought and added it earlier, but I see your point now with DenseConjunctionBulkScorer. got a bit confused there, thanks! removed the guard. one thing I kept is the ConstantScoreScorer wrapper delegating intoBitSet to the underlying iterator. without that, it falls back to the slow per-doc loop and misses the bulk implementation from the delegate. this isn’t a guard, just making sure we use the underlying API properly. Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
