[
https://issues.apache.org/jira/browse/LUCENE-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267972#comment-15267972
]
ASF subversion and git services commented on LUCENE-7262:
---------------------------------------------------------
Commit 5b51479b69ec3c52e42c9b95418ee285080311f7 in lucene-solr's branch
refs/heads/branch_6x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5b51479 ]
LUCENE-7262: Fix NPE, this should lazy-init in start()
(cherry picked from commit 91153b9)
> Add back the "estimate match count" optimization
> ------------------------------------------------
>
> Key: LUCENE-7262
> URL: https://issues.apache.org/jira/browse/LUCENE-7262
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Fix For: master, 6.1
>
> Attachments: LUCENE-7262.patch, LUCENE-7262.patch, LUCENE-7262.patch
>
>
> Follow-up to my last message on LUCENE-7051: I removed this optimization a
> while ago because it made things a bit more complicated but did not seem to
> help with point queries. However the reason why it did not seem to help was
> that the benchmark only runs queries that match 25% of the dataset. This
> makes the run time completely dominated by calls to FixedBitSet.set so the
> call to FixedBitSet.cardinality() looks free. However with slightly sparser
> queries like the geo benchmark generates (dense enough to trigger the
> creation of a FixedBitSet but sparse enough so that FixedBitSet.set does not
> dominate the run time), one can notice speed-ups when this call is skipped.
--
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
