dungba88 commented on PR #14226: URL: https://github.com/apache/lucene/pull/14226#issuecomment-2710421110
> this is where we first search pro-rated across segments, and then if any segment has its output queue full with competitive hits, we revisit it using the prior hits as entry points and a queue size of K (the full original K). Yes that's correct > My only question is whether lambda=2 is correct - the graphs show lambda 6+ looking more reasonable, and indeed they don't seem to show a data point for 2 at all? I've benchmarked with the minimum of 3 so there is no data points for 2. For lambda=3, it's interesting that the simplified version is slower than the optimistic version. This is (somewhat) expected as with the simplified version on the second pass we immediately use the queue size of k (k=100 here) while the optimistic version will gradually increase the queue size, so that it may end up with a size much less than k. When we increase lambda, the difference becomes diminished as there is less re-entry needed and the queue size difference would also be smaller. -- 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: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
