Community
Participate
Working Groups
Cloned from: 12: The Quest for Performance: more efficient matcher nodes and match retrieval API http://github.com/ujhelyiz/EMF-IncQuery/issues/issue/12 * Retrieving the whole match set is O(n), and part of this time overhead is copying tuples into ReteMatches, and then into the generated Match object. This should be streamlined somehow. * More efficient Collection implementations should be investigated as well.
Some uncertain ideas: * a pattern is simple iff has only one body with no local variables to eliminate [questionable optimizations, handle with care] + omit the production node (or use a memoryless one) and / or the trimmer node (and no reordering required) somehow + reuse indices between the trimmer node, the body terminator (parent of the trimmer node) and the production node (if any), cleverly compensating for different variable ordering? + alternatively, if called from a different pattern, use the body terminator since variable ordering does not matter here anyway; avoid building the trimmer and the production node unless necessary (indexes are shared anyways?)
I'm setting version to "unspecified" as we currently do not (firmly) know when these future ideas will be addressed.
Closing old IncQuery issues that have not been worked on in the past 2-3 years.
