[
https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713067#action_12713067
]
Michael McCandless commented on LUCENE-1614:
--------------------------------------------
bq. Leaving the code as-is means that someone thought of a case where a
sub-scorer will have more documents to collect, but still after the 2nd code
segment the bucketTable was empty.
This would happen when none of the sub-scorers had docIDs in the
current bucket range.
EG say the first docID of all sub-scorers is 3000,
and BucketTable.SIZE is 2048. On the first time through part (2), no
sub-scorer will add to the bucket, so on finishing part (2),
bucketTable.first will still be null but more will be true, and so the
whole loop would (and, should) keep repeating.
I think?
So in fact your change should break that case.... can you add a
breaking unit test showing this?
Also, I wonder if this can be removed, by init'ing the sub-scorers up
front:
{code}
if (doc == -1) {
doc = scorer.nextDoc();
}
{code}
> Add next() and skipTo() variants to DocIdSetIterator that return the current
> doc, instead of boolean
> ----------------------------------------------------------------------------------------------------
>
> Key: LUCENE-1614
> URL: https://issues.apache.org/jira/browse/LUCENE-1614
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Shai Erera
> Fix For: 2.9
>
> Attachments: LUCENE-1614.patch, LUCENE-1614.patch, LUCENE-1614.patch
>
>
> See
> http://www.nabble.com/Another-possible-optimization---now-in-DocIdSetIterator-p23223319.html
> for the full discussion. The basic idea is to add variants to those two
> methods that return the current doc they are at, to save successive calls to
> doc(). If there are no more docs, return -1. A summary of what was discussed
> so far:
> # Deprecate those two methods.
> # Add nextDoc() and skipToDoc(int) that return doc, with default impl in DISI
> (calls next() and skipTo() respectively, and will be changed to abstract in
> 3.0).
> #* I actually would like to propose an alternative to the names: advance()
> and advance(int) - the first advances by one, the second advances to target.
> # Wherever these are used, do something like '(doc = advance()) >= 0' instead
> of comparing to -1 for improved performance.
> I will post a patch shortly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
