jpountz commented on issue #11676:
URL: https://github.com/apache/lucene/issues/11676#issuecomment-1307598183
Sorry for the confusion, I was thinking of not relying on any timing info
**at all** besides the one that is already encapsulated by the `QueryTimeout`
object. Just relying on the fact that if we haven't hit the timeout yet, and
then score a window that is 50% larger, then we wouldn't exceed the timeout by
much.
E.g. increasing the window by 50% on every iteration in order to limit the
overhead of timeout checks.
- collect 100 docs
- collect 150 docs
- collect 225 docs
- collect 337 docs
- collect 505 docs
- collect 757 docs - Worst-case scenario: the timeout was hit right after
starting collecting so we collected 757 docs after the timeout. Yet we had
collected 1317 docs before the timeout, so we only exceeded the expected
timeout by 57%.
It's not very smart, but I like that:
- It's simple.
- It doesn't require exposing how much time is left on the `QueryTimeout`
object, only whether the timeout was hit or not yet.
--
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
