DefaultQueryCache entrySet inefficient result building

[TomaszGaweda]

Hi,

DefaultQueryCache handles queries to query caches. However, it's performance is degradated because of current flow in case of index aware query:

1. get results from index
2. if not null -> check isEmpty (which traverse whole result set!)
3. again ask for query.size() - here it's not so bad, because size result is cached after point 2
4. again traverse result set and add to final HashSet

This should be much faster: if query is not null, isEmpty should look only if any element was found; what's more, we can at first construct resultingSet, without isEmpty and size calls, because this eager optimization causes in real life huge performance degradation.

[ahmetmircik]

Hi @TomaszGaweda,

if not null -> check isEmpty (which traverse whole result set!)

Can you please give reference to this issue? Where does it happen in the code?

[TomaszGaweda]

@ahmetmircik
Hi, thanks for the quick response :)

Please look at DefaultQueryCache.entrySet: https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/map/impl/querycache/subscriber/DefaultQueryCache.java#L364

Algorithm is currently as follows:

1. indexes.query returns i.e. AndPredicate (most commonly used in a predicate tree root).
2. if result is not null, we call query.isEmpty(), which falls back to AbstractCollection.isEmpty. This method is implemented as size() == 0.
3. Size is implemented as follows: https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/query/impl/AndResultSet.java#L146
4. ok, we have some entries - then we call size() again to create HashSet of some size, this time result is cached, so no big problem.
5. Next we iterate using for-each loop over the result of indexes.query -> this will again create AndResultSet$It and iterate whole Query Cache.

In case of "big" Query Caches (~2000) entries and compound predicates it can consume a lot of time

[ahmetmircik]

should be fixed by #14229