Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SYSML-25] Improve performance for searching uml class with the right stereotype #49

Closed
cbrun opened this issue Dec 10, 2013 · 9 comments

Comments

@cbrun
Copy link
Member

cbrun commented Dec 10, 2013

[reporter="ejuliot", created="Mon, 6 Aug 2012 12:05:47 +0200"]

Today, you use "[getStereotypeApplications().filter('sysml::Block')/]" to find class which have the Block stereotype.
(and you do the same thing for every query).

As the profiler say it's one of the raison of the poor performance of Sysml Designer, we need to optimise it.

Several proposition:
1) check if static profil could improve performance

2) use another service.
For exemple : [getAppliedStereotype('sysml::Block')/]
and [isStereotypeApplied('sysml::Block')/] (with a new service to use String instead of Stereotype)

@cbrun
Copy link
Member Author

cbrun commented Dec 10, 2013

[author="cbrun", created="Mon, 6 Aug 2012 17:39:06 +0200"]

Calling "getStereotypeApplications" in the semantic candidate expression instead of the precondition will reduce it's call numbers by an order of magnitudes. Should probably the first thing to try.

@cbrun
Copy link
Member Author

cbrun commented Dec 10, 2013

[author="cbrun", created="Mon, 6 Aug 2012 17:54:26 +0200"]

Oddly I can't reproduce the fact that such expressions would appear in the profiling view.

Could you describe the scenario to reproduce it and attach the needed models ?

@cbrun
Copy link
Member Author

cbrun commented Dec 10, 2013

[author="ejuliot", created="Mon, 6 Aug 2012 17:57:15 +0200"]

I just use the alarm radio exemple, and try to use the block creation tool, in the bdd diagram.
I have to expand the detail of the profiling to see this expression.

@cbrun
Copy link
Member Author

cbrun commented Dec 10, 2013

[author="cbrun", created="Mon, 6 Aug 2012 19:02:40 +0200"]

By the way changing the preference "automatic refresh" to false makes the whole experience a very good one.

@cbrun
Copy link
Member Author

cbrun commented Dec 10, 2013

[author="cbrun", created="Mon, 6 Aug 2012 19:07:47 +0200"]

Opening the alarm radio example, creating a new block, and then creating another one, I get 1 to 2 sec delay before the block is created.

Looking at the profiling view after several creations, I get arround 5sec in refresh, the getStereotypeApplications->filter stuffs are representing a few ms each, 228 ms in total.

Most of the time (4sec) is spent in "get edge's candidate" and more especialy in "[self/]" evaluation (1.3 sec) and "2.03" in "other".

@cbrun
Copy link
Member Author

cbrun commented Dec 10, 2013

[author="ejuliot", created="Tue, 7 Aug 2012 10:04:00 +0200"]

And the first time you create an element or you delete it, it's still 5 sec.

So, we had to focus on edge mappings which seems to be one of the main raison of this pb.

@cbrun
Copy link
Member Author

cbrun commented Dec 10, 2013

[author="cbrun", created="Tue, 12 Mar 2013 21:15:51 +0100"]

Now that the edge mapping issue looks better (see https://support.jira.obeo.fr/browse/SYSML-23) , I'm back on this one.

As commented earlier, getStereotypeApplication() is not going up in the culprit list, that said this expression :
[self.getStereotypeApplications()->filter(sysml::blocks::Block)->size() > 0 and self.getStereotypeApplications()->filter(sysml::constraints::ConstraintBlock)->size() = 0/]

takes a bit of time (something like 5/8% of the total refresh time. It's not going to be a game changer but even just for the sake of readibility it might be worthit to factorise it in a Java service.

@mbats
Copy link
Member

mbats commented Dec 26, 2013

Done during the migration to Sirius.

@mbats mbats closed this as completed Dec 26, 2013
@mbats
Copy link
Member

mbats commented Dec 27, 2013

Valid for 4.0.0_M1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants