[SYSML-23] Improve performance on Requirement Table and BDD representations

[cbrun]

[reporter="ejuliot", created="Fri, 20 Jul 2012 14:50:20 +0200"]

There are still problesm of perf :

• bdd 1st time : 7s pour the first element
• bdd : 3s for the next creation
• requirement table : 20s the first time

Test done with the alarm radio example.

[cbrun]

[author="mbats", created="Wed, 1 Aug 2012 15:31:52 +0200"]

Sysml profile resource is loaded each time the createAssociatesStereotype is called, the resource is also loaded by the activator so use the activator to get the Sysml Profile. Fixed in commit 1d0a4d3.

[cbrun]

[author="mbats", created="Wed, 1 Aug 2012 15:41:15 +0200"]

Lots of time spent to refresh the diagram, works in progress in Acceleo and VP to solve this problem.

[cbrun]

[author="mbats", created="Wed, 1 Aug 2012 15:43:14 +0200"]

Wait for new version of OD6 and Acceleo3

[cbrun]

[author="mbats", created="Fri, 3 Aug 2012 09:10:33 +0200"]

Validated with build 1.0.2.201208020955

[cbrun]

[author="cbrun", created="Tue, 7 Aug 2012 10:51:19 +0200"]

Re-opened as measured times are still behind what we expect. Using the viewpoint profiler we can see [self/] evaluation is still very costly (1/4 of the refresh time) for what it does, even called 10 000 times.

[cbrun]

[author="cbrun", created="Thu, 9 Aug 2012 15:40:36 +0200"]

https://support.jira.obeo.fr/browse/VP-3390 has been integrated on the Obeo Designer 6.0.2 branch.

A new test reveals way better performances, between 1 to 2 sec for a block creation. It should still be improved but it looks like now Acceleo 3 is not the biggest culprit anymore.

Other first class candidates is now the process invovled in the refresh of edges. It looks 80% of time is spent on "Other" which only means it is not related to expressions anymore.

[cbrun]

[author="cbrun", created="Mon, 11 Mar 2013 15:53:10 +0100"]

Another quick analysis : the "Dependency", "Generalization" and "Association" EdgeMappings are good candidates for bad performances as they have many possible start/end mappings (at least 5 each time) leading to an explosive number of potential candidates to check. Furthermore as they are domain class mappings, with no semantic candidates, the whole modeling session (all the resourceset) is going to be browsed to find potential candidates and then check them with the nodes currently in the diagram.

I am reluctant to go back to a "Relation based Edges" as that would introduce lot of changes and would be like twisting the mapping spirit to our aim, that said I think we could keep the "Domain based Edges" but come up with a semantic candidate expression which uses the current diagram (and so the currently displayed nodes) to find the candidates Dependency/Association/Interface whatsoever by using the cross referencer.

We would move from a computation which is a factor of the model size to one which is a factor of the diagram content (and that would be applicable for any semi unsynchronized diagram in UML too)

[cbrun]

[author="cbrun", created="Tue, 12 Mar 2013 17:18:54 +0100"]

Looks like we can enhance the situation a great deal with the same approach as in UML-265.

[cbrun]

[author="cbrun", created="Tue, 12 Mar 2013 18:32:45 +0100"]

Applying the same technique as UML-265 I have a great speedup, that said it still is not perfect because of the BDD_Verify and BDD_Satisfy Edge mappings which I can't get my grasp on.

Disabling the Requirement layer (and as such these mappings) I have a 1sec delay creating a new block (including the full refresh)