[
https://issues.apache.org/jira/browse/LUCENE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887469#comment-13887469
]
Shai Erera commented on LUCENE-5425:
------------------------------------
The current patch's intention seems to allow the app to cache FixedBitSet, such
that it can clear() it before each search? To save the long[] allocation? This
looks fine to me. Can you please add javadocs to FC.createBitSet?
bq. Better not to depend on the bitset, it's better to depend on a more general
interface.
We need to be careful here. Mike and I experimented with cutting the API over
to a general DocIdSet, but it hurt the performance of faceted search, even with
"smarter" bitsets. When we move to a DocIdSet, we add the DocIdSetIterator
layer while iterating over the bits which slows down the search ... at least
per luceneutil benchmarks. So if we want to do that, we should do it only after
proving, by means of benchmarking, that it doesn't hurt performance severely.
Would actually be good to show that more compressed bitsets maybe even improve
performance, but I would go with the change if the performance-loss is
marginal. And we should do it under a separate issue, to not block this one.
> Make creation of FixedBitSet in FacetsCollector overridable
> -----------------------------------------------------------
>
> Key: LUCENE-5425
> URL: https://issues.apache.org/jira/browse/LUCENE-5425
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
> Affects Versions: 4.6
> Reporter: John Wang
> Attachments: facetscollector.patch
>
>
> In FacetsCollector, creation of bits in MatchingDocs are allocated per query.
> For large indexes where maxDocs are large creating a bitset of maxDoc bits
> will be expensive and would great a lot of garbage.
> Attached patch is to allow for this allocation customizable while maintaining
> current behavior.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
