[
https://issues.apache.org/jira/browse/LUCENE-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13889910#comment-13889910
]
Paul Elschot commented on LUCENE-5416:
--------------------------------------
I would normally expect that the performance is independent of the presence of
the advanceToJustBefore() method of DocBlockIterator.
This method happens to be there because I needed it for LUCENE-5092, and I did
not bother to remove it for the performance measurements.
I'm sorry for the confusion about this.
The FixedBitSetDBI here does not always make nextDoc() faster, in fact (for me)
the Long.numberOfTrailingZeros() implementation of nextDoc() in FixedBitSetDBI
here is up to 5 times slower for load factors above 0.25. Below that the
nextDoc() here is up to 2.5 times faster.
The idea is that using Long.numberOfTrailingZeros() appears to be faster for
advance(), and also for nextDoc() up to a load factor of about 0.25 .
Wasn't OpenBitSetIterator made before Long.numberOfTrailingZeros() was
available/intrinsified?
> Performance of a FixedBitSet variant that uses Long.numberOfTrailingZeros()
> ---------------------------------------------------------------------------
>
> Key: LUCENE-5416
> URL: https://issues.apache.org/jira/browse/LUCENE-5416
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
> Affects Versions: 5.0
> Reporter: Paul Elschot
> Priority: Minor
> Fix For: 5.0
>
>
> On my machine the current byte index used in OpenBitSetIterator is slower
> than Long.numberOfTrailingZeros() for advance().
> The pull request contains the code for benchmarking this taken from an early
> stage of DocBlocksIterator.
> In case the benchmark shows improvements on more machines, well, we know what
> to do...
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
