[
https://issues.apache.org/jira/browse/LUCENE-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14499958#comment-14499958
]
Adrien Grand commented on LUCENE-6427:
--------------------------------------
To be honest this doesn't look like a valid use-case of scanIfEmpty to me. As
the code comment suggests, we should rewrite this code to not check that the
bitset is empty in a loop. In practice we are trying to move away from these
linear-time operations of FixedBitSet (nextDoc(), cardinality(), ...) as much
as we can. For instance when we use this class for query execution (for
multi-term queries mainly), we strive to only use a FixedBitSet if we know that
the set of documents that we are going to store is dense enough for FixedBitSet
to not be slower than a sparser implementation.
Other than the new unused methods (scanIfEmpty and LongBitset.flip) the PR
looks good to me now.
> BitSet fixes - assert on presence of 'ghost bits' and others
> ------------------------------------------------------------
>
> Key: LUCENE-6427
> URL: https://issues.apache.org/jira/browse/LUCENE-6427
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/other
> Reporter: Luc Vanlerberghe
>
> Fixes after reviewing org.apache.lucene.util.FixedBitSet, LongBitSet and
> corresponding tests:
> * Some methods rely on the fact that no bits are set after numBits (what I
> call 'ghost' bits here).
> ** cardinality, nextSetBit, intersects and others may yield wrong results
> ** If ghost bits are present, they may become visible after ensureCapacity is
> called.
> ** The tests deliberately create bitsets with ghost bits, but then do not
> detect these failures
> * FixedBitSet.cardinality scans the complete backing array, even if only
> numWords are in use
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
