Consider adding support to use lambda functions as attributes about cqengine HOT 4 CLOSED

Hi langzhaozhi, I'm accepting this suggestion, thanks.

I plan that the next major version of CQEngine will integrate more closely with Java 8 features such as lambdas and method handles. Especially method handles, would simplify attributes a lot.

The current version is compatible with Java 6, so these changes are not yet possible. Hopefully in the new year I can do it though. Thanks!

from cqengine.

This is now done. When run on Java 8, CQEngine 2.8.0 now allows attributes to be created from lambda expressions. It was possible to implement this in a way that retained compatibility with Java 6 & 7, so CQEngine still works with those earlier versions of Java too.

from cqengine.

How about primitives support to avoid boxing? It was also suggested above but I'm not sure if it's done.

Should support the primitives types of attributes, like DoubleFunction IntFunction similar in java8. The reason is that queries are often in a large amount of data application, CQEngine should try every possible way to eliminate the performance loss of the automatic boxing and unboxing in order to achieve the highest efficiency

from cqengine.

I don't think this would be a high priority or much of a problem.

Boxing overhead is usually a much bigger problem than unboxing overhead, and boxing overhead should already be mitigated to a large extent.

Currently all primitives are stored in boxed form when using on-heap persistence and indexes. So it means there should not be any boxing overhead during query processing. There will be unboxing overhead, but this does not produce any garbage.

Off-heap persistence and indexes store data in primitive format. This means when suitable indexes are available to support the query during query processing, the values from queries will be unboxed and compared with primitive values inside indexes. So this entails unboxing (not boxing) as well, which means there should not be much boxing/GC overhead either.

However if the collection is using off-heap persistence or indexes, but certain queries can't be answered from a single index, then filtering will be performed. Filtering can involve deserializing objects speculatively to check if they match the query, which can be quite expensive. However in applications where this is a problem, an alternative "merge" strategy can be configured (the index merge strategy) which performs joins between indexes instead of deserializing objects speculatively, which can reduce that overhead.

So I think we need to see actual evidence of boxing or unboxing being a performance bottleneck before making API changes to support primitives. If anybody wants to do some proof of concepts or testing in this area I'd be open to collaborating though!

from cqengine.