[ https://issues.apache.org/jira/browse/LUCENE-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267967#comment-15267967 ]
ASF subversion and git services commented on LUCENE-7262: --------------------------------------------------------- Commit 91153b9627d7bd9e17dcb4762ebbaf26bc3410f4 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=91153b9 ] LUCENE-7262: Fix NPE, this should lazy-init in start() > 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