[
https://issues.apache.org/jira/browse/LUCENE-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-7262:
---------------------------------
Attachment: LUCENE-7262.patch
Here is a new patch. It also uses statistics to figure out whether the int[]
needs to remove duplicates in the sparse case. When I patch the LatLon queries
to use DocIdSetBuilder instead of MatchingPoints and run the geo benchmark, I
get the following QPS:
||benchmark||DocIdSetBuilder||DocIdSetBuilder + patch||
|distance|47.3|48.7|
|poly 5|35.2|35.6|
So there is a noticeable speedup.
> 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
> Attachments: 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: [email protected]
For additional commands, e-mail: [email protected]
