Hi

You shouldn't expect too much with 1M graphical elements. Graphical representations have non-trivial overheads.

How big is your VM? You can see from Fig 16 of [1] that even manual code starts to fail at 10M EMF elements in a 4GB VM. A simple EMF activity such as EcoreUtil copy may take nearly 10 seconds on 10M elements on an ordinary PC. Poor code may easily go unacceptably quadratic.

In practice there are no doubt many algorithms in Sirius that can be improved, but until then you would be well advised to consider approaches that reduce the number of model elements. Otherwise get a really big fast PC.

Regards

Ed Willink

[1] http://www.eclipse.org/mmt/qvt/docs/ICMT2017/MicromappingMoC.pdf

Hi, thanks for trying to reproduce the benchmark. We are always pushing further from a performance perspective and having a model with 1 Million elements is definitely manageable though require a bit of setup to not go into dead ends, among others: efficient serialization format (not XMI), diagrams which are users constructed and focused on one aspect of the model, small work on the memory layout of the model (see this checklist http://cedric.brun.io/eclipse/ecore-design-checklist-part2/ )

I often see a lot of assumptions which are just completely off the mark regarding performances when we look at the machines we have now and the improvements done in EMF, Sirius and even Java.

I just reproduced the benchmark myself by using a Obeo Designer Community Edition 10.0 which i had on my machine and could reproduce these times. Note that this project is even sub-optimal as having a single binary file holding all the model would probably require less (I would bet on half the time, but that needs to be checked)

My machine is a Lenovo X240 on Linux Opensuse 42.2, Java 1.8.0_73-b02.
I used this archived project: https://bugs.eclipse.org/bugs/attachment.cgi?id=254581

I just uploaded a video showing exactly what I did: https://www.youtube.com/watch?v=qJ4rRpufSVI&feature=youtu.be

Thanks for the details.

1. No it's not possible to show millions of elements in one diagram in Sirius, it has not been designed to support such use cases from a performance and user experience perspective.
2. It might depend on what you consider exactly an "element" in a diagram, but roughly speaking 1000 elements in the diagram is the right order of magnitude.
3. That would require deep changes in Sirius itself, in the underlying technologies and also probably in the way the diagram would be defined. At that point the better way to support such use cases would be to implement a new "Dialect" from scratch (Table, Tree and Diagram supports are dialects) with an editor able to do that.

HI

IIRC Sirius has an ability to populate a diagram from seeds then gradually add neighbours.

You could therefore manually choose distinct nodes in your design that you want to focus on and create a diagram around each of them.

One could imagine a create-multiple-class-diagrams wizard that offered a check list in which the central nodes of each diagram are selected and a neighbourhood distance configured. One could even imagine a heuristic that preselected the central nodes to achieve complete coverage with a near minimal number of central nodes.

Regards

Ed Willink