Re: Slow performance

Martin Matula <[email protected]> Fri, 11 Jul 2003 09:23:17 +0200
Newsgroups gmane.comp.java.netbeans.modules.mdr.devel
Message-ID <[email protected]>
And btw., there is a newer version of Looks API than the one we are 
using in MDR Explorer. It is located in openide/looks. I am not sure how 
independent it is from NetBeans - hopefully you can use it without too 
much other stuff from NetBeans. I am CC'ing Petr Hrebejk (its author) 
who can help to answer your questions if you are interested.
Martin

Martin Matula wrote:
> Hi Anders,
> what you plan to do with perspectives is exactly what our Looks API does 
> - maybe you can reuse it. MDR Explorer is implemented using Looks API. 
> Currently we have ony two "looks" (perspectives) - reflective and MOF.
> Martin
> 
> Anders W. Tell wrote:
> 
>> Thanks Martin !
>>
>> Removing the derived did the trick.
>>
>> With regards to this particular traversal , Im just in the beginning 
>> of creating a workbench ( see attached image). Im creating a generic 
>> mechanis for defining perspectives+navigationSteps and this 
>> perspective is the naive one. More perspectives are to follow and Ill 
>> have look at MDR views and principles later on. Certainly  pure 
>> reflective, MOF, UML15 and UML2 perspectives are needed. Right now Im 
>> focusing to get the framework going.
>>
>> The perspectives with their navigationSteps may be dynamically 
>> registered and when dsiplaying an object, a lookup is performed and 
>> the perspectives that canHandle(Object target) are displayed in the 
>> topleft navigator.
>>
>> Kind regards
>> /anders
>> Martin Matula wrote:
>>
>>> Hi Anders,
>>> I think the reason why the operation is so slow is because of the 
>>> DependsOn association defined in MOF. It is defined so that it should 
>>> return all the objects that a given object depends on (by any kind of 
>>> other relationships/associations) transitively. This basically means 
>>> that every object is in "DependsOn" relationship with any other 
>>> object. I am not sure about the usefulness of this association in MOF 
>>> but it is there and we have to implement it. Anyway, when you are 
>>> doing this kind of iteration, you should rather restrict the 
>>> iteration only to non-derived associations - those carry all the 
>>> original information. DependsOn is just a derived association (it is 
>>> computed when you access it from the other associations). To do this, 
>>> you should modify your code in a following way:
>>> > for all in outermost.refAllPackages -> pkg
>>> >  for all in pkg.refAllAssociations ->  as
>>>       if (!((Association) as.refMetaObject()).isDerived())
>>> >         for all in as.refAllLinks
>>>               ...
>>>
>>> Btw., why are you doing this kind of iterations for the JTree you 
>>> want to construct? If you know you are operating on the MOF metamodel 
>>> (reading information about UML metamodel), you can build the tree 
>>> based on containment hierarchy (as we did it for MOF extents in MDR 
>>> explorer).
>>> If you want to build a generic browser, you may want to show separate 
>>> node for each association and fetch the data from MDR only when the 
>>> association node is expanded. Also you may consider exploring the 
>>> metamodel and show all the references of a class under each object 
>>> node and make navigation from a given object to the related objects 
>>> possible (as we did it in the "reflective" view in MDR Explorer).
>>> Or do I misunderstand your goal?
>>> Regards,
>>> Martin
>>> ---
>>>
>>> Anders W. Tell wrote:
>>>
>>>> Hi,
>>>>
>>>> Im creating a UI for viewing MDR /JMI artifacts for the UML 15. 
>>>> metamodel. When doing the following traversal MDR takes for ever to 
>>>> complete.
>>>>
>>>> for all in outermost.refAllPackages -> pkg
>>>>  for all in pkg.refAllAssociations ->  as
>>>>     for all in as.refAllLinks
>>>>        --- here it loops calling 
>>>> ModelElementImpl.recursiveFindDeps,  ---
>>>>
>>>> Basically I want to form a JTree with the artifacts in UML 15 
>>>> metamodel. Im using the memory database not BTREE for fast performance.
>>>>
>>>> Is this a common problem or is a problem with the loop or ....
>>>>
>>>> cheers
>>>> /anders
>>>>
>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
> 
>