I see three major TODOs:
1. We have to make concrete measurements in order to see how much of a performance overhead there is for “during traversal” or “post matching” containment filtering. 2. Based on the conclusions derived from these measurements, a “compatibility matrix” needs to be determined in order to identify (scope, matcher type) combinations that make sense. 3. The API and the documentation (both Javadoc and wiki) has to be updated accordingly.
Marci, can you take charge of this?
cheers Istvan On 9 Sep 2015 at 09:35:23, Ujhelyi Zoltán (ujhelyiz@xxxxxxxxxxxxxxxx) wrote: Hi,
my answers are inline.
> On 09 Sep 2015, at 08:31, István Ráth <rath@xxxxxxxxxx> wrote:
>
> Hi,
>
> I was trying to find the “official” documentation on queries/scopes vs. cross-resource references, but couldn’t immediately find them on https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API nor on https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API/Advanced. (By the way: to what degree are these pages outdated w.r.t. 1.0.0?) Does anyone know where it is / should be?
I don’t think such a documentation exists (maybe outside of Javadoc). We have a very old ticket corresponding to some issues even we have found here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398907
> Anyway, I think the behavior of LS and Rete should be functionally equivalent, i.e. both should respect the matching scope according to the same semantics. In other words, an EObject should only be returned in the match set iff it is considered to be part of the scope of the matcher. As far as I know, our scope definition currently does rely on the containment hierarchy (as highlighted by your findings).
> So in the short term, LS should also follow this. I’m not sure about the performance impact though - I guess this is just an additional check when navigating relations and easy to measure in terms of overhead. Could you do this?
Yes, it is based on the containment hierarchy, and since 1.0 we also support multiple model roots here + filtering there.
The problem here is that navigating happens _very_ often, so adding a containment check for each of these can add up to be expensive (depending on the depth of the containment hierarchy). There are cases when this can be executed cheaply (e.g. when the target type is indexed in Base), but not in general. If multiple model roots are enabled together with filtering, this check becomes even more expensive...
Maybe a post-search filtering is more feasible, but I have my doubts there as well.
>
> In the longer term however, maybe we can consider introducing an additional flag to relax this, however my gut feeling is that this is really only feasible for non-Base-indexer LS configurations - Gaben correct me if I’m wrong.
I guess, this is the main question of the previously linked bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=398907
Cheers,
Zoli
-- Zoltán Ujhelyi
Technology Expert
IncQueryLabs Ltd.
_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incquery-dev
--
István Ráth
Research Fellow Fault Tolerant Systems Research Group Budapest University of Technology and Economics http://inf.mit.bme.hu/en/members/rath rath@xxxxxxxxxx |
