| Issues with collectReachableObjectsOfType [message #631727] |
Fri, 08 October 2010 09:55  |
Eclipse User |
|
|
|
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 11:43  |
| Eclipse User |
|
|
|
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 #631828 is a reply to message #631817] |
Fri, 08 October 2010 18:41 |
| Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.03913 seconds
Home