[jira] Issue Comment Edited: (LUCENE-2383) Some small fixes after the flex merge...

["Uwe Schindler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854681#action_12854681 ] 

Uwe Schindler edited comment on LUCENE-2383 at 4/7/10 8:24 PM:
---------------------------------------------------------------

FCRF looks ok, I would only change the nextDoc() loop in the deletions-aware iterator to:

{code}
do {
  doc++;
  if (doc >= maxDoc)
    return doc = NO_MORE_DOCS;
} while (skipDocs.get(doc) || !matchDoc(doc));
return doc;
{code}

and the same in advance(), little bit changed:

{code}
for (doc = target; doc < maxDoc; doc++) {
  if  (!skipDocs.get(doc) && matchDoc(doc))
    return doc;
}
return doc = NO_MORE_DOCS;
{code}

The try catch is then unneeded. This seems clearer for me. The non-skipdocs iterator is performanter with the try...catch, as it preserves one bounds check. But we need to do the bounds check here in all cases, why not do up-front?

      was (Author: thetaphi):
    FCRF looks ok, I would only change the nextDoc() loop in the deletions-aware iterator to:

{code}
do {
  doc++;
  if (doc >= maxDoc) return NO_MORE_DOCS;
} while (skipDocs.get(doc) || !matchDoc(doc));
return doc;
{code}

and the same in advance(), little bit changed:

{code}
for (doc = target; doc < maxDoc; doc++) {
  if  (!skipDocs.get(doc) && matchDoc(doc))
    return doc;
}
return NO_MORE_DOCS;
{code}

The try catch is then unneeded. This seems clearer for me. The non-skipdocs iterator is performanter with the try...catch, as it preserves one bounds check. But we need to do the bounds check here in all cases, why not do up-front?
  
> Some small fixes after the flex merge...
> ----------------------------------------
>
>                 Key: LUCENE-2383
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2383
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 3.1
>
>         Attachments: LUCENE-2383.patch
>
>
> Changes:
>   * Re-introduced specialization optimization to FieldCacheRangeQuery;
>     also fixed bug (was failing to check deletions in advance)
>   * Changes 2 checkIndex methods from protected -> public
>   * Add some missing null checks when calling MultiFields.getFields or
>     IndexReader.fields()
>   * Tweak'd CHANGES a bit
>   * Removed some small dead code

-- 
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org