Community
Participate
Working Groups
There are many places in Sirius where we iterate on model contents using eAllContents() or equivalent. This does not scale, and we suspect than in many of these cases a full walk is not actually necessary. It's difficult to find the culprits statically in the code base, as there are many many places where such walks are ttiggered. A quick search gives about 140 direct calls to eAllContents() in the Sirius code base, not counting the helpers which call it indirectly, the code from library/frameworks we use that walk the omdels, and the other ways equivalent walks can happen in less obvious ways (e.g. recursive calls to eContents()). Even if we take an actual instance of such a walk in the code, it is not always obvious to determine the user-level scenario or operations which will activate the code, and thus to decide which instances are more important to fix. An alternative approach could be to craft a specific metamodel to be used as semantic model for Sirius with appropriate instrumentation to detect when such model walks occur. Using such a model on representative usage scenarios could help us pinpoint the actual locations in Sirius code which trigger the most problematic cases.
This instrumentation should allow us to sure that *when an implementer of a the API defined in Bug 456410 is provided for a specific resource* the Sirius runtime will not trigger un-necessary model browsing. As you said, instrumenting a metamodel sounds like a usefull thing to do : 1- a domain model with parts of it which are never ever supposed to be used or visible in the tooling : a containment reference which is not displayed through the item providers) and containing instances which are not used by the tooling in any way (that's what I called the "payload") 2- instrumented getXXX() implementation which are allowing us to "track" who called it, maybe by keeping stacktraces around and making sure we can easily get them back at any time, even with interactive manipulation of the tool. We could keep the stacktraces around as an instance field and expose them as EObjects through a derived containment reference. 3- a .odesign which is specified in a way we are sure the getXXX() method has no reason to be browsed. 4- an implementation of the API defined in Bug 456410 which will just ignore the reference leading to the payload in the case of such models/resource.
First idea: * Define a minimal metamodel with just a recursive container type (say "Component") with a few basic attributes and a multi-valued non-containment reference to allow for test cases with inter-elements links. * Define a PayloadMarkerAdapter, which can be attached to any number of elements. The adapter stores a "journal" of accesses to the elements marked with it. * Tweak the generated implementation of the Component type's getXXX() for both containment and non-containment references. When such a getter is invoked, check if the Component has a PayloadMarkerAdapter, and if so log the access (with the elements' URI and a full stacktrace) into the adapter.
See https://git.eclipse.org/r/#/c/39189/ and https://git.eclipse.org/r/#/c/39190/ for a first iteration on the metamodel and payload access detection code.
Created attachment 249852 [details] Sample payload model and basic modeler Using the metamodel and helper actions in https://git.eclipse.org/r/#/c/39189/ and https://git.eclipse.org/r/#/c/39190/, the attached sample probject can be used to detect suspect accesses to parts of the semantic model: 1. Make sure the sample metamodel and the "Sirius Debug View" are available in your enviroment. 2. Launch a runtime. 3. Import the sample project in attachement (or something equivalent). 4. Open the "Sirius Debug View". 5. Click on "Clear Payload Access Log", and then "Show Payload Access Log". The log should be empty. 6. Perform some user-level scenario, for example opening the session. If the scenario involves multimple steps (in practice all of them exception "opening the session"), clear the log right before the interesting step to avoid pollution with data relative to the earlier steps. 7. Click on "Show Payload Access Log" to see a report of how much payload accesses were recorder and all the unique contexts that lead to them. Note that there may be some duplications in the contexts if payload elements appear at multiple depth in the model (some stacks will be considered different even if they are logically equivalent except for their depth). It can also be useful to put a breakpoint in org.eclipse.sirius.sample.component.util.PayloadMarkerAdapter.logAccess(Setting). Do not hesitate the improve the data gathered by PayloadMarkerAdapter and the reporting in SiriusDebugView.addShowPayloadAccessLogAction().
I believe this can be considered as done now. There will certainly be some adjustments and improvements to make it more useful for certain use cases, but the version currently on master works as intended for the general use case.
Verified on Sirius 3.0.0M6
Available in Sirius 3.0.0. See https://wiki.eclipse.org/Sirius/3.0.0.
