lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Koen De Groote (JIRA)" <j...@apache.org>
Subject [jira] [Created] (SOLR-13542) Code cleanup - Avoid using stream filter count where possible
Date Thu, 13 Jun 2019 00:00:00 GMT
Koen De Groote created SOLR-13542:
-------------------------------------

             Summary: 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


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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message