Home » Modeling » EMF » [Dawn] DawnGMFHandler.Adapter Notifications, Performance Issue
| [Dawn] DawnGMFHandler.Adapter Notifications, Performance Issue [message #743434] |
Fri, 21 October 2011 13:23  |
 Bjoern Sundin
Messages: 19
Registered: July 2009
Location: Switzerland |
Junior Member |
|
|
Hi again Martin,
First of all I have to say, that my tests using Dawn still look very promising. I have good faith in being able to adopt it into my application. It is quite a specialized application and so far I could integrate Dawn into it with only minor adjustments in the generated code, mainly in regards to initiating the diagram and its resource (as I don't use any generated creation wizard).
In my project, an Engineering Configuration Application, I have two CDO resources, one is the actual model and one is the GMF diagram resource (now using Dawn). Both are stored in the same CDO server repository.
The model resource has a root object ("environment") being represented by the diagram itself. There can only be one diagram in the application. The other visible parts on the diagram canvas are "connectables" (ShapeNodeEditParts), which are directly contained in the root object, and connections (ConnectionNodeEditParts, source edge containment in connectables).
Environment (EditPart: Diagram)
|
Connectable (EditPart: ShapeNodeEditPart)
|
Connection (EditPart: ConnectionNodeEditParts)
|
<Rest of containment tree> (No EditParts)
In the diagram there are usually only between 2 to 20 connectables. Below the connectables in the Ecore containment tree there is a complex structure of objects. Those objects are not part of the diagram, but graphically represented by custom views (tables and trees).
So the only relation with any EditPart is over the containment in the "connectable" model object.
There might be between 10.000 to 1.000.000 objects in the containment tree of such a resource instance.
In order to be able to do efficient engineering of such a project there are several file imports automatically creating all the model objects and adding any "connectable" and its connections to the diagram. It is during such an import I programmatically invoke the semantic edit policy in order to create model object as well as the EditParts for the diagram. The underlying objects are created directly using the appropriate EMF factory.
Since I started using Dawn I encounter a severe performance issue during such an import. As far as I can see is it caused in the DawnGMFHandler and DawnDiagramUpdater from where cascades of notifications are issued.
Now, I'm not quite sure how to approach this problem and thus I ask for some help from a "Dawn Point of View".
It seems that the Adapter declared in the DawnGMFHandler is attached to all model objects having a "connectable" as eContainer (and recursively further down the containment tree?).
During the import I obviously have to CREATE, SET and ADD many times in different objects. This triggers an enormous amount of notifications to refresh the diagram parts. For each model object being "touched" the root object is being recursively searched, the diagram view, and its childnodes, located and the diagram gets refreshed.
I believe I need to find the right way to tell the Adapter in the DawnGMFHandler whether it is a relevant model object or not. In my case I do not have any EditPart compartments with underlying model objects, so there is no need to refresh for each modification (or adding) of child objects.
Experimenting a bit with eSetDeliver(false) resp. eSetDeliver(true) on the different objects brings a remarkable improvement, however that is a "hack" which side effects I cannot completely foresee (how does other adapters react and what is getting missed?).
Maybe one could make the DawnGMFHandler and also the DawnDiagramUpdater aware of the org.eclipse.gmf.runtime.emf.type.core.elementTypes and the semantic hints? If I understand it correctly, then Dawn would just be concerned about the diagram elements and their binding to semantic objects?
I would really appreciate any input in regards to this matter. 
Cheers
Björn
|
|
|
| Re: [Dawn] DawnGMFHandler.Adapter Notifications, Performance Issue [message #743586 is a reply to message #743434] |
Fri, 21 October 2011 15:39  |
Martin Fluegge
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Hi Björn,
again, comments inline... ;)
Am 21.10.2011 15:23, schrieb Bjoern Sundin:
> Hi again Martin,
>
> First of all I have to say, that my tests using Dawn still look very
> promising. I have good faith in being able to adopt it into my
> application. It is quite a specialized application and so far I could
> integrate Dawn into it with only minor adjustments in the generated
> code, mainly in regards to initiating the diagram and its resource (as I
> don't use any generated creation wizard).
> In my project, an Engineering Configuration Application, I have two CDO
> resources, one is the actual model and one is the GMF diagram resource
> (now using Dawn). Both are stored in the same CDO server repository.
> The model resource has a root object ("environment") being represented
> by the diagram itself. There can only be one diagram in the application.
> The other visible parts on the diagram canvas are "connectables"
> (ShapeNodeEditParts), which are directly contained in the root object,
> and connections (ConnectionNodeEditParts, source edge containment in
> connectables).
>
> Environment (EditPart: Diagram)
> |
> Connectable (EditPart: ShapeNodeEditPart)
> |
> Connection (EditPart: ConnectionNodeEditParts) |
> <Rest of containment tree> (No EditParts)
>
>
That is quite close the the Acore example, so this might not be the
source of the problem.
> In the diagram there are usually only between 2 to 20 connectables.
> Below the connectables in the Ecore containment tree there is a complex
> structure of objects. Those objects are not part of the diagram, but
> graphically represented by custom views (tables and trees). So the only
> relation with any EditPart is over the containment in the "connectable"
> model object.
> There might be between 10.000 to 1.000.000 objects in the containment
> tree of such a resource instance.
Well, this is definitively not comparable to the Dawn example ;)
> In order to be able to do efficient engineering of such a project there
> are several file imports automatically creating all the model objects
> and adding any "connectable" and its connections to the diagram. It is
> during such an import I programmatically invoke the semantic edit policy
> in order to create model object as well as the EditParts for the
> diagram. The underlying objects are created directly using the
> appropriate EMF factory.
> Since I started using Dawn I encounter a severe performance issue during
> such an import. As far as I can see is it caused in the DawnGMFHandler
> and DawnDiagramUpdater from where cascades of notifications are issued.
>
> Now, I'm not quite sure how to approach this problem and thus I ask for
> some help from a "Dawn Point of View".
> It seems that the Adapter declared in the DawnGMFHandler is attached to
> all model objects having a "connectable" as eContainer (and recursively
> further down the containment tree?).
Do you mean the anonymous adapter in DawnGMFHandler.modifyingObject()?
>
> During the import I obviously have to CREATE, SET and ADD many times in
> different objects. This triggers an enormous amount of notifications to
> refresh the diagram parts. For each model object being "touched" the
> root object is being recursively searched, the diagram view, and its
> childnodes, located and the diagram gets refreshed.
>
> I believe I need to find the right way to tell the Adapter in the
> DawnGMFHandler whether it is a relevant model object or not. In my case
> I do not have any EditPart compartments with underlying model objects,
> so there is no need to refresh for each modification (or adding) of
> child objects.
>
> Experimenting a bit with eSetDeliver(false) resp. eSetDeliver(true) on
> the different objects brings a remarkable improvement, however that is a
> "hack" which side effects I cannot completely foresee (how does other
> adapters react and what is getting missed?).
This is not the best approach. I think we should address this to the
Dawn GMF extension.
>
> Maybe one could make the DawnGMFHandler and also the DawnDiagramUpdater
> aware of the org.eclipse.gmf.runtime.emf.type.core.elementTypes and the
> semantic hints?
Create idea. Please file a bug for this issue. If you mean the adapter
mentioned above than I can imagine that this can lead to some serious
performance issues when modifying the objects locally. Only changes in
objects that really have a view representation should lead to a refresh.
> If I understand it correctly, then Dawn would just be
> concerned about the diagram elements and their binding to semantic
> objects?
The GMF part of Dawn should only care about the elements represented in
the diagram. The EMF editor is certainly interested in other objects
(actually al in the resource) ;)
Cheers,
Martin
|
|
|
| Re: [Dawn] DawnGMFHandler.Adapter Notifications, Performance Issue [message #747841 is a reply to message #743586] |
Mon, 24 October 2011 10:10 |
Bjoern Sundin
Messages: 19
Registered: July 2009
Location: Switzerland |
Junior Member |
|
|
Hi Martin,
Also my comments inline...
Cheers Björn
...
>> First of all I have to say, that my tests using Dawn still look very
>> promising. I have good faith in being able to adopt it into my
>> application. It is quite a specialized application and so far I could
>> integrate Dawn into it with only minor adjustments in the generated
>> code, mainly in regards to initiating the diagram and its resource (as I
>> don't use any generated creation wizard).
>> In my project, an Engineering Configuration Application, I have two CDO
>> resources, one is the actual model and one is the GMF diagram resource
>> (now using Dawn). Both are stored in the same CDO server repository.
>> The model resource has a root object ("environment") being represented
>> by the diagram itself. There can only be one diagram in the application.
>> The other visible parts on the diagram canvas are "connectables"
>> (ShapeNodeEditParts), which are directly contained in the root object,
>> and connections (ConnectionNodeEditParts, source edge containment in
>> connectables).
>>
>> Environment (EditPart: Diagram)
>> |
>> Connectable (EditPart: ShapeNodeEditPart)
>> |
>> Connection (EditPart: ConnectionNodeEditParts) |
>> <Rest of containment tree> (No EditParts)
>>
>>
>That is quite close the the Acore example, so this might not be the
>source of the problem.
I must admit I am not familiar with the Acore example... :-/
>> In the diagram there are usually only between 2 to 20 connectables.
>> Below the connectables in the Ecore containment tree there is a complex
>> structure of objects. Those objects are not part of the diagram, but
>> graphically represented by custom views (tables and trees). So the only
>> relation with any EditPart is over the containment in the "connectable"
>> model object.
>> There might be between 10.000 to 1.000.000 objects in the containment
>> tree of such a resource instance.
>Well, this is definitively not comparable to the Dawn example 
>> In order to be able to do efficient engineering of such a project there
>> are several file imports automatically creating all the model objects
>> and adding any "connectable" and its connections to the diagram. It is
>> during such an import I programmatically invoke the semantic edit policy
>> in order to create model object as well as the EditParts for the
>> diagram. The underlying objects are created directly using the
>> appropriate EMF factory.
>> Since I started using Dawn I encounter a severe performance issue during
>> such an import. As far as I can see is it caused in the DawnGMFHandler
>> and DawnDiagramUpdater from where cascades of notifications are issued.
>>
>> Now, I'm not quite sure how to approach this problem and thus I ask for
>> some help from a "Dawn Point of View".
>> It seems that the Adapter declared in the DawnGMFHandler is attached to
>> all model objects having a "connectable" as eContainer (and recursively
>> further down the containment tree?).
>Do you mean the anonymous adapter in DawnGMFHandler.modifyingObject()?
Yes
>>
>> During the import I obviously have to CREATE, SET and ADD many times in
>> different objects. This triggers an enormous amount of notifications to
>> refresh the diagram parts. For each model object being "touched" the
>> root object is being recursively searched, the diagram view, and its
>> childnodes, located and the diagram gets refreshed.
>>
>> I believe I need to find the right way to tell the Adapter in the
>> DawnGMFHandler whether it is a relevant model object or not. In my case
>> I do not have any EditPart compartments with underlying model objects,
>> so there is no need to refresh for each modification (or adding) of
>> child objects.
>>
>> Experimenting a bit with eSetDeliver(false) resp. eSetDeliver(true) on
>> the different objects brings a remarkable improvement, however that is a
>> "hack" which side effects I cannot completely foresee (how does other
>> adapters react and what is getting missed?).
>This is not the best approach. I think we should address this to the
>Dawn GMF extension.
I fully agree with you here.
>>
>> Maybe one could make the DawnGMFHandler and also the DawnDiagramUpdater
>> aware of the org.eclipse.gmf.runtime.emf.type.core.elementTypes and the
>> semantic hints?
>Create idea. Please file a bug for this issue. If you mean the adapter
>mentioned above than I can imagine that this can lead to some serious
>performance issues when modifying the objects locally. Only changes in
>objects that really have a view representation should lead to a refresh.
I filed a bug under https://bugs.eclipse.org/bugs/show_bug.cgi?id=361788
I also added the idea to use an extension point to let plugin clients define a NotificationFilter. I am not sure that one from the dawn plugin can determine if a notification is relevant for the view object or not. This knowledge is more problable at the implementors side? I am thinking here on a model object whose features partly are defined in the diagram view, i.e. a name, a description and maybe some child compartment. But also containing some huge list of objects changing quite often and not being part of the visual model.
>> If I understand it correctly, then Dawn would just be
>> concerned about the diagram elements and their binding to semantic
>> objects?
>The GMF part of Dawn should only care about the elements represented in
>the diagram. The EMF editor is certainly interested in other objects
>(actually al in the resource)
That's good, I also see it this way!
|
|
|
Goto Forum:
Current Time: Thu Apr 18 23:24:19 GMT 2024
Powered by FUDForum. Page generated in 0.02717 seconds |
] 
Search
Help
Register
Login
Home
