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

Yonik Seeley commented on LUCENE-3443:
--------------------------------------

bq. I think we should commit this, first, then separately optimize the valid 
bits to single pass....

That represents a pretty significant performance regression though, and it 
seems we should try to avoid stuff like that on trunk (better in a branch if 
one is going to remove functionality with the idea of adding it back later).  
Or we could generate the bits by default - the extra cache entry if not needed 
is less serious than doubling the generation time.

Another small piece we are losing from trunk is numUniqueTerms.
What about returning an object, so instead of getLongs() returning a long[], it 
would return a LongValues that had
a long[] as well as numUniqueTerms, and docsWithValues (optionally set).  This 
also halves the number of cache lookups needed when using sortMissinglast and 
supplies a place to put more info in the future (stuff like numUniqueTerms).
                
> Port 3.x FieldCache.getDocsWithField() to trunk
> -----------------------------------------------
>
>                 Key: LUCENE-3443
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3443
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/search
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 3.5, 4.0
>
>         Attachments: LUCENE-3443.patch
>
>
> [Spinoff from LUCENE-3390]
> I think the approach in 3.x for handling un-valued docs, and making it
> possible to specify how such docs are sorted, is better than the
> solution we have in trunk.
> I like that FC has a dedicated method to get the Bits for docs with field
> -- easy for apps to directly use.  And I like that the
> bits have their own entry in the FC.
> One downside is that it's 2 passes to get values and valid bits, but
> I think we can fix this by passing optional bool to FC.getXXX methods
> indicating you want the bits, and the populate the FC entry for the
> missing bits as well.  (We can do that for 3.x and trunk). Then it's
> single pass.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to