Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Performance issues during element selection
Hi Christian, hi all,

The tree may not need to be facet-extensible, but its "basic" presentation may be facet-based anyway.
For instance, in SCADE System, all trees (in browser and in selection dialogs) look the same.
They are not (as of now) further extensible, but they are not a plain UML view over the model either, and this custom view is based on facets.
We had to be particularly careful when implementing the queries to avoid bottlenecks
(typically returning "virtual" collections with fast "isEmpty" implementation for example, among other tricks).

Regards,
Alain Le Guennec

On Tue, Mar 8, 2016 at 1:36 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Ansgar,

Indeed, my own opinion is that a dialog in which the user is asked to select elements for setting reference properties doesn’t need to be facet-extensible at all.  What the user can select is only model content (not notations), so Papyrus should just use a simple tree content provider that shows the model content.  Otherwise, there’s the question of how to know which facet queries to include or exclude?  The component that is showing the dialog has no way of knowing which queries inject unneeded stuff into the tree.  The faceted trees are good for the Model Explorer, but I don’t really see them having a place in these dialogs.

Cheers,

Christian

On 8 March, 2016 at 05:23:17, RADERMACHER Ansgar 206501 (ansgar.radermacher@xxxxxx) wrote:

Dear all,

the element selection in the property view (e.g. choosing a type for an attribute or assigning a value to a stereotype attribute) has severe performance issues: the UI can be blocked for several minutes even for mid-sized models. See Bug 435352 -[Property view] Attribute selection takes way too long.

The main reason is that the element selection is based on EMF Facet and each registered facet slows down the process.
One problem is that each facet implements a getChildren/hasChildren operation that links model elements with notation elements. The implementation of these operations is iterating over all notation elements and thus quite inefficient, since notation elements reference model elements but not vice versa.
Thus, the element search that loops over all model elements, implies several inner loops over all notation elements thus implying a quadratic effort.
It gets worse, since elements can be found via different paths, e.g. directly via the working set or via (nested) package imports. Thus, elements in imported models are queried several times.

One option is the caching of references from model to notation elements, as proposed in the gerrit attached to the bug (a long time ago) . Eventually, we can also use the EMF inverse-referencing mechanism for the navigation.

Another option is to disable the lookup of notation elements temporary during an element lookup - since notation elements are never selectable during an element assignment.

Other ideas?

Best regards

Ansgar

_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

Back to the top