Eclipse Community Forums: Sirius » Duplication memory in Sirius, GMF or EMF?

Help

Home

Home » Eclipse Projects » Sirius » Duplication memory in Sirius, GMF or EMF?

Show: Today's Messages :: Show Polls :: Message Navigator

Duplication memory in Sirius, GMF or EMF? [message #1775006]

Mon, 23 October 2017 12:42

mind calm

Messages: 57
Registered: July 2017

Member

HI,

I found a interesting phenomenon, if i create a Sirius diagram for a big size model (100,000), the biggest memory consumer is object array (java.long.object[]), it occupied over 80% memory.

And I found many of the object array stores NodeImpl instances, but the size of these array is reduced one by one (Show in the pictures). This cause the memory grows in speed of O(n²) by model size. I think this may be a memory leak or bad strategy in somewhere.

Attachment: 1.png
(Size: 130.55KB, Downloaded 138 times)
Attachment: 2.png
(Size: 114.15KB, Downloaded 117 times)
Attachment: 0.png
(Size: 103.60KB, Downloaded 110 times)

Best regards!

by Keep Mind Calm

[Updated on: Mon, 23 October 2017 12:46]

Report message to a moderator

Re: Duplication memory in Sirius, GMF or EMF? [message #1775052 is a reply to message #1775006]

Tue, 24 October 2017 08:45

Pierre Guilet

Messages: 250
Registered: June 2017

Senior Member

Hi,

Thank you for your analyse.

If I understand correctly these arrays are referenced by feature changes that are not meant to be persistent but more punctual.
So these should be garbageable at some point.
I imagine it grows only from a short time when node are loaded maybe or in another situation.

Regards,

Pierre

Pierre Guilet - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius

[Updated on: Tue, 24 October 2017 09:10]

Report message to a moderator

Re: Duplication memory in Sirius, GMF or EMF? [message #1775057 is a reply to message #1775052]

Tue, 24 October 2017 09:09

Pierre Guilet

Messages: 250
Registered: June 2017

Senior Member

What is your analysis context?
100,000 is the number of semantic elements or do you have diagrams with 100,000 graphical element?
When do take the snapshot for analysing? After opening a diagram, the project?

Pierre Guilet - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius

Report message to a moderator

Re: Duplication memory in Sirius, GMF or EMF? [message #1775063 is a reply to message #1775057]

Tue, 24 October 2017 09:28

mind calm

Messages: 57
Registered: July 2017

Member

Hi, Pierre Guilet

Thanks for your reply!

100,000 is the number of graphical elements in the Sirius diagram.
After i created the diagram and opened it, i did several times GC, then take the "Heap dump" operation. I analyse the heapdump file. So, maybe other Objects reference to "FeatureChangeImpl" instance indirectly, then bring this problem.

Best regards!

by Keep Mind Calm

Report message to a moderator

Re: Duplication memory in Sirius, GMF or EMF? [message #1775090 is a reply to message #1775063]

Tue, 24 October 2017 13:27

Pierre Guilet

Messages: 250
Registered: June 2017

Senior Member

Ok feature changes are kept for undo/redo purpose so they can be present in memory for some time until it is cleared either by crossing a limit or a save I guess.

It works with an old/new value mechanic. So if you add a node in a list, your change will have as old value the old list and as new value a new list containing the new node.
The difference must be kept to be able to reverse the change.
So I don't think we can do much about it.

However GMF deals not really well with this kind of graphical element number for one diagram. If you could split this number with more representations you would have more efficiency.
This would be a huge challenge to handle such number of elements.

Pierre Guilet - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius

Report message to a moderator

Re: Duplication memory in Sirius, GMF or EMF? [message #1775293 is a reply to message #1775090]

Fri, 27 October 2017 09:48

mind calm

Messages: 57
Registered: July 2017

Member

Hi, Pierre Guilet

After i created a Sirius diagram and opened it, I checked the undolist in DefaultOperationHistory, found it only contains two EMFCommandOperations. One of the EMFCommandOperations which contains CreateRepresentatinCommand, that contains many FeatureChangeImpl instances.

I think the CreateRepresentatinCommand and RefreshRepresentatinCommand should not support the undo function, i override the canUndo() function in these two command, but it didn't work.

Another thing, while executing CreateRepresentatinCommand, it will create many NodeImpl instances. Each creation of NodeImpl instance will create a new transaction and the transaction will produce the ChangeDescription (I do not very clear about this process).
I guess if the creation of NodeImpl do not use transaction, maybe the memory problem will be resolved.

Best regards!

by Keep Mind Calm

Report message to a moderator

Re: Duplication memory in Sirius, GMF or EMF? [message #1775467 is a reply to message #1775293]

Mon, 30 October 2017 14:30

Pierre Guilet

Messages: 250
Registered: June 2017

Senior Member

Hi,

In Sirius the representation creation is done with the following code in org.eclipse.sirius.ui.business.api.editor.SpecificEditorInputTranformer.createDRepresentation(EObject, String):

  CreateRepresentationCommand command = new CreateRepresentationCommand(session, descriptionToUse, semanticModel, name, new NullProgressMonitor());
            session.getTransactionalEditingDomain().getCommandStack().execute(command);

If you really want to try something, you can provide your own editing domain by using the org.eclipse.sirius.common.editingDomainFactory extension point. This editing domain of yours will provide your own command stack that will not keep commands with feature changes you don't want.
This could work if I am not missing something big.

Regards,

Pierre

Pierre Guilet - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius

Report message to a moderator