[ https://issues.apache.org/jira/browse/LUCENE-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14497795#comment-14497795 ]
Luc Vanlerberghe commented on LUCENE-6427: ------------------------------------------ * I moved the "Depends on the ghost bits being clear!" line from the doc comments to a regular comment, except for the constructor (where the fact is verified if assertions are enabled) * I renamed checkIfEmpty to scanIsEmpty and updated comments. I don't see the problem with having a scanIsEmpty method available for those willing to look for it. It probably will make a performance difference for small bitsets because it avoids the overhead of two method calls and the numberOfTrailingZeros call in nextSetBit on the first non-zero long. LUCENE-5856 shows that even removing a useless & 0x3f from *BitSet.get and company can have a noticeable effect (albeit probably in tight inner loops) By the way, I did remove a useless & 0x3f from FixedBitSet.flip in this patch as well > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org