aherbert commented on pull request #258:
URL:
https://github.com/apache/commons-collections/pull/258#issuecomment-995996222
Yes, IntPredicate is functionally identical. In general I would expect the
performance of a throw-catch to be worse than a for loop with a break on a
boolean evaluation result. The lack of an explicit early exit strategy is a
problem with the JDK 8 forEach consumer pattern. There is no way to stop
consuming values. For the case of the BloomFilter where the primary use case is
to check if a collection (the Bloom filter) does not already contain an item
(new hash value) then early exit will be key to performance when the
BloomFilter has lots of items.
I wonder about the speed of this default operation:
```java
default boolean contains(BloomFilter other) {
Objects.requireNonNull(other, "other");
return isSparse() ? contains((IndexProducer) other) :
contains((BitMapProducer) other);
}
```
Is the `isSparse` result cached on update by implementations? Otherwise a
filter will do a traversal of its entire bit state to get the cardinality to
compute if it is sparse, then pick the best contains method. Which may then do
another full traversal of the bit state.
IIUC the `isSparse` helps to choose if a filter is best iterated using the
IndexProducer or BitMapProducer interface. So should it be decided based on if
the other BloomFilter is sparse:
```java
return other.isSparse() ? contains((IndexProducer) other) :
contains((BitMapProducer) other);
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
