Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EMF][EMFStore][Sirius] Change Operations and graphs
[EMF][EMFStore][Sirius] Change Operations and graphs [message #1587777] Tue, 27 January 2015 14:58 Go to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 233
Registered: July 2009
Senior Member
As the title shows, this posting covers a number of areas. We are using Sirius for diagrams in an EMFStore environment and are experiencing some performance and management issues.

The way that changes are recorded seem to be to record every operation happening during the session and not only to have a list of operations that represent the diff at save time. This would be akin to a VCS recording every keystroke instead of just a delta at commit/save time.

Anyway, we end up with thousands (and tens of thousands) of operations when generating diagrams or when a user does some layouting. Layouting is the worst culprit for creating floods of operations. We understand that diagram by their very nature will create a much larger number of operations, but here it is multiplied to the extreme.

On the pure EMF side, we see that the change recorder make a list copy on every change and this is done with resolving list which forces a scan of all elements which get progressively slower and drags the application as the pool of operation grows. Can't this be improved by avoiding constant list copies or trying to resolve (we see no real resolution going on)?

Next why is it necessary to capture every operation and not only to capture a final delta?

How are diagrams like Sirius / GMF working for others in an environment like EMFStore that tracks all changes like this?

On a side note, when committing such change sets with tens of thousands of operations describing how you re-arranged a couple of diagram, the commit information looses all its value, can it be grouped so that it can be made meaningful?

Thanks
Alain

Re: [EMF][EMFStore][Sirius] Change Operations and graphs [message #1590250 is a reply to message #1587777] Wed, 28 January 2015 23:02 Go to previous messageGo to next message
Louis-Frederic Huppe-St-Hilaire is currently offline Louis-Frederic Huppe-St-HilaireFriend
Messages: 2
Registered: January 2015
Junior Member
Colleague of Alain's here.

As we investigated the set of issues he outlined, we noticed that much of the performance degradation we observed as we created Sirius diagrams came from the fact that the list of change operations maintained in ChangePackage is itself monitored for changes. This list, which can grow to contain well over 100k operations in our case, therefore gets repetitively copied/shuffled around by the change recorder, the main culprits being ChangeRecorder.handleFeature() and BasicChangeRecorder.finalizeChange().

Acknowledging this, we have attempted a fix which consists in overriding ChangeRecorder.shouldRecord() and excluding the feature holding change operations in ChangePackage. Performance has dramatically improved as a result, but we aren't completely sure that this modification won't have unforeseen side-effects.

Does anybody see potential problems with this approach? Or could propose a better alternative?

LF
Re: [EMF][EMFStore][Sirius] Change Operations and graphs [message #1591562 is a reply to message #1587777] Thu, 29 January 2015 16:00 Go to previous message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 253
Registered: July 2009
Senior Member
Hi Alain,

I will try to answer your questions inline...

> The way that changes are recorded seem to be to record every operation
> happening during the session and not only to have a list of operations
> that represent the diff at save time. This would be akin to a VCS
> recording every keystroke instead of just a delta at commit/save time.
This is correct, every change on the model is recorded as one operation.
If you have a databinding which writes to the model on every keystroke
it potentially means every keystroke is recorded as an operation. You
could avoid this by changing the update policy in the databinding.
Nevertheless EMFStore will record every change you do one the model
while you change the model. This is fundamentally different from e.g.
EMFCompare which derives the changes after they have been performed.
Maybe this documentation can help clarify how things work in EMFStore
and why:
http://eclipsesource.com/blogs/tutorials/emfstore-versioning-history-and-branching/
There is advantages and drawbacks to both - change-based/operation-based
Versioning (EMFStore) and state-based Versioning (EMFCompare).

> Anyway, we end up with thousands (and tens of thousands) of operations
> when generating diagrams or when a user does some layouting. Layouting
> is the worst culprit for creating floods of operations. We understand
> that diagram by their very nature will create a much larger number of
> operations, but here it is multiplied to the extreme.

> On the pure EMF side, we see that the change recorder make a list copy
> on every change and this is done with resolving list which forces a scan
> of all elements which get progressively slower and drags the application
> as the pool of operation grows. Can't this be improved by avoiding
> constant list copies or trying to resolve (we see no real resolution
> going on)?
Yes, it could be. Currently the implementation of the operation list is
based on EMF. Changing it to an optimized list for this purpose would
definitely speed up things significantly. Maybe this is a contribution
you could make or you could sponsor an open-source implementation.

> Next why is it necessary to capture every operation and not only to
> capture a final delta?
This is related to operation-based versioning as mentioned above. I know
of non-open-source extensions to EMFStore which later consolidate the
list of operation by canonizing multiple related changes into one, but
there is no open-source solution to my knowledge at this point.

> How are diagrams like Sirius / GMF working for others in an environment
> like EMFStore that tracks all changes like this?
We have customers using huge diagrams with EMFStore. Mostly they use
composite operations to wrap all the small operations related to a
diagram change into one composite operation. Nevertheless there will be
many small operations in the composite. It just helps with atomicity in
conflict detection/merging and with visualization.

> On a side note, when committing such change sets with tens of thousands
> of operations describing how you re-arranged a couple of diagram, the
> commit information looses all its value, can it be grouped so that it
> can be made meaningful?
See my comment above. With composite operations you can make
visualization a lot more compact and usable.

Hope this helps a bit! ;)

Cheers,
Maximilian
>
> Thanks
> Alain
>
>


--
Maximilian Kögel

Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
Previous Topic:[EMFStore] Commit error with SingleReferenceOperation
Next Topic:[Texo] Building a CRUD client
Goto Forum:
  


Current Time: Fri Apr 10 17:47:30 GMT 2020

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

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

Back to the top