[
https://issues.apache.org/jira/browse/SOLR-13542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koen De Groote updated SOLR-13542:
----------------------------------
Description:
This is another ticket in the logic of
https://issues.apache.org/jira/browse/LUCENE-8847
Not a feature, not serious, don't review this when you could be reviewing
actual features or critical bugs, don't want to take your time away with this.
Intellij's static code analysis bumped into this.
I also saw most other instances in the code where such a filter needed to
happen already used
{code:java}
anyMatch{code}
instead of count(). So I applied the suggested fixes. Code cleanup and
potentially a small performance gain. As far as my understanding goes, since it
is not a simple count that's happening, there's no known size for the evaluator
to return and as such it has to iterate over the entire collection. Whereas
anyMatch and noneMatch will use the predicate to stop the instance the
condition is met.
It just so happens that all affected instances exist within the SolrJ namespace.
All tests have run, all succeed.
EDIT: Github PR: https://github.com/apache/lucene-solr/pull/717
was:
This is another ticket in the logic of
https://issues.apache.org/jira/browse/LUCENE-8847
Not a feature, not serious, don't review this when you could be reviewing
actual features or critical bugs, don't want to take your time away with this.
Intellij's static code analysis bumped into this.
I also saw most other instances in the code where such a filter needed to
happen already used
{code:java}
anyMatch{code}
instead of count(). So I applied the suggested fixes. Code cleanup and
potentially a small performance gain. As far as my understanding goes, since it
is not a simple count that's happening, there's no known size for the evaluator
to return and as such it has to iterate over the entire collection. Whereas
anyMatch and noneMatch will use the predicate to stop the instance the
condition is met.
It just so happens that all affected instances exist within the SolrJ namespace.
All tests have run, all succeed.
> Code cleanup - Avoid using stream filter count where possible
> -------------------------------------------------------------
>
> Key: SOLR-13542
> URL: https://issues.apache.org/jira/browse/SOLR-13542
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
> Reporter: Koen De Groote
> Priority: Trivial
>
> This is another ticket in the logic of
> https://issues.apache.org/jira/browse/LUCENE-8847
>
> Not a feature, not serious, don't review this when you could be reviewing
> actual features or critical bugs, don't want to take your time away with this.
>
> Intellij's static code analysis bumped into this.
>
> I also saw most other instances in the code where such a filter needed to
> happen already used
> {code:java}
> anyMatch{code}
> instead of count(). So I applied the suggested fixes. Code cleanup and
> potentially a small performance gain. As far as my understanding goes, since
> it is not a simple count that's happening, there's no known size for the
> evaluator to return and as such it has to iterate over the entire collection.
> Whereas anyMatch and noneMatch will use the predicate to stop the instance
> the condition is met.
> It just so happens that all affected instances exist within the SolrJ
> namespace.
>
> All tests have run, all succeed.
>
> EDIT: Github PR: https://github.com/apache/lucene-solr/pull/717
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
