Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Issues with collectReachableObjectsOfType
Issues with collectReachableObjectsOfType [message #631727] Fri, 08 October 2010 13:55 Go to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
As discussed by others a few years ago, collectReachableObjectsOfType is
aggressively looking at the whole model, and when dealing with a "root"
model that manages proxy references to a set of very huge models, this
forces the loading of the whole graph, which can be millions of objects
(over 14 millions reported from YourKit in my case) from all the
referenced models.

I probably can turn off the resolve proxy and that might avoid this
situation, but that would force us to revise some of the code that
expects on-demand loading of those models (1 by 1 normally, never all of
them).

But in looking at the current collectReachableObjectsOfType, I can't
understand why it needs to visit the whole graph.

I have a reference feature point to class C which extends class B and
class A has a containment relation to class B.

X --has feature --> Y
Y --reference of type --> C

C --extends --> B
A --containment to --> B

So the only way to get to C is to get the containment list of A and
filter those elements which are of type C (not other subtypes of B).

So why can't collectReachableObjectsOfType actually apply such logic
instead of looking at tons of unrelated objects?

Thanks for helping me understand here.

Alain
Re: Issues with collectReachableObjectsOfType [message #631753 is a reply to message #631727] Fri, 08 October 2010 15:43 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30551
Registered: July 2009
Senior Member
Alain,

Comments below.

Alain Picard wrote:
> As discussed by others a few years ago, collectReachableObjectsOfType
> is aggressively looking at the whole model, and when dealing with a
> "root" model that manages proxy references to a set of very huge
> models, this forces the loading of the whole graph, which can be
> millions of objects (over 14 millions reported from YourKit in my
> case) from all the referenced models.
>
> I probably can turn off the resolve proxy and that might avoid this
> situation, but that would force us to revise some of the code that
> expects on-demand loading of those models (1 by 1 normally, never all
> of them).
>
> But in looking at the current collectReachableObjectsOfType, I can't
> understand why it needs to visit the whole graph.
Objects of the right type can be lurking anywhere.
>
> I have a reference feature point to class C which extends class B and
> class A has a containment relation to class B.
>
> X --has feature --> Y
> Y --reference of type --> C
>
> C --extends --> B
> A --containment to --> B
>
> So the only way to get to C is to get the containment list of A and
> filter those elements which are of type C (not other subtypes of B).
Of course anyone can subtype any of these classes and introduce features
that make it possible reach objects of types you might not expect just
looking at the base model.
>
> So why can't collectReachableObjectsOfType actually apply such logic
> instead of looking at tons of unrelated objects?
Because of open ended derivation, there's no way to guarantee that you
can't reach objects of any particular type.
>
> Thanks for helping me understand here.
I think only if your domain is bounded can you apply this type of
analysis. I.e., if you know all EClass that might be used in the
instance, you could determine the possibility of reachability by the
analysis you've outlined.
>
> Alain
>
>
Re: Issues with collectReachableObjectsOfType [message #631774 is a reply to message #631753] Fri, 08 October 2010 17:10 Go to previous messageGo to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
Ed,

> Objects of the right type can be lurking anywhere.
> Because of open ended derivation, there's no way to guarantee that you
> can't reach objects of any particular type.

Ok, I get that this is possible, but wouldn't it be better and faster to
analyze the base and reachable model(s) and identify if they indeed
subtype the type in question and if they do then if there is some
containment that can be followed. This metadata introspection can be
used to prepare an "intelligent query plan" and to skip it all together
if the plan shows no such possibilities in external models. In all cases
it would be faster to analyze the meta-models than to brute force
ourselves through the models. Or are we looking to find "EObject"
attributes to be able to contain anything and everything here?

Thanks
Alain
Re: Issues with collectReachableObjectsOfType [message #631802 is a reply to message #631774] Fri, 08 October 2010 20:01 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30551
Registered: July 2009
Senior Member
Alain,

Comments beow.

Alain Picard wrote:
> Ed,
>
>> Objects of the right type can be lurking anywhere.
>> Because of open ended derivation, there's no way to guarantee that you
>> can't reach objects of any particular type.
>
> Ok, I get that this is possible, but wouldn't it be better and faster
> to analyze the base and reachable model(s) and identify if they indeed
> subtype the type in question and if they do then if there is some
> containment that can be followed. This metadata introspection can be
> used to prepare an "intelligent query plan" and to skip it all
> together if the plan shows no such possibilities in external models.
> In all cases it would be faster to analyze the meta-models than to
> brute force ourselves through the models. Or are we looking to find
> "EObject" attributes to be able to contain anything and everything here?
Suppose we have some EObject x whose class is X and that class has a
containment reference foo to class Y. Until I do o.eGet(foo) and look
at the EClass of the result, I won't know if it's a Y or some class Z
derived from Y and it might well be the case that given X and Y there's
no way to no that Z exists. It could be in some model I don't know
about yet. So it gets back to my comment about an analysis being
definitive only if you know all possible classes you might encounter.
I imagine for many clients you really would know that this set of
packages is all I use in my application. It would certainly be
interesting to explore to how exploit that for more efficient visiting...
>
> Thanks
> Alain
Re: Issues with collectReachableObjectsOfType [message #631817 is a reply to message #631802] Fri, 08 October 2010 21:31 Go to previous messageGo to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
On 10/8/2010 4:01 PM, Ed Merks wrote:
> So it gets back to my comment about an analysis being definitive
> only if you know all possible classes you might encounter. I imagine for
> many clients you really would know that this set of packages is all I
> use in my application. It would certainly be interesting to explore to
> how exploit that for more efficient visiting...

IMHO, this is one of the good reason why we do modeling in the first
place and is probably the "normal" use case. That being said I
understand how some cases can stretch this and where the current
approach is the only fully safe one in all cases, but surely not the
generally most efficient (or even usable as our case shows).

Alain
Re: Issues with collectReachableObjectsOfType [message #631828 is a reply to message #631817] Fri, 08 October 2010 22:41 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30551
Registered: July 2009
Senior Member
Alain,

Comments below.

Alain Picard wrote:
> On 10/8/2010 4:01 PM, Ed Merks wrote:
>> So it gets back to my comment about an analysis being definitive
>> only if you know all possible classes you might encounter. I imagine for
>> many clients you really would know that this set of packages is all I
>> use in my application. It would certainly be interesting to explore to
>> how exploit that for more efficient visiting...
>
> IMHO, this is one of the good reason why we do modeling in the first
> place and is probably the "normal" use case.
The code that does the visiting doesn't know all models until it visits
all objects. And even then, it doesn't know that the next time it
visits the objects, that there won't be yet more new models. Keep in
mind that this code is used even in cases where models are dynamically
loaded...
> That being said I understand how some cases can stretch this and where
> the current approach is the only fully safe one in all cases, but
> surely not the generally most efficient (or even usable as our case
> shows).
The current approach is the only fully general one. But as I said, it
would definitely be interesting to explore support for the case of a
bounded set of packages. It's definitely something that modeling makes
possible!
>
> Alain
Previous Topic:ChangeRecorder: Ignore Notifications of Transient EStructuralFeatures
Next Topic:RAP Version of EM Transaction and EMF Validation
Goto Forum:
  


Current Time: Sat Oct 19 10:42:41 GMT 2019

Powered by FUDForum. Page generated in 0.02257 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top