Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Sirius » Too many tools and sections in Palette, make slow Node creation and search
Too many tools and sections in Palette, make slow Node creation and search [message #1697621] Fri, 05 June 2015 12:42 Go to next message
Le Chau Nguyen is currently offline Le Chau NguyenFriend
Messages: 19
Registered: August 2012
Junior Member
Hi All,

There are a lot of tool in my Viewpoint Specification Design file, near to 400 tools (corresponding to ~400 Nodes), grouped in 24 sections.
Due to my special requirements, I can not reduce these number of tool.

That causes 2 issues:

- It is very slow when I create a new Node by select Tool, then drop in Canvas. The Node appears after at least 4-5 seconds after dropping.
When I tested with 20 tools only, it is very fast. So the problems is in the number of Nodes.
I think maybe Sirius does some validation before drawing it on Canvas.
Could anyone suggest me how I optimize this? Which Sirius extension I should extend to modify the drop behavior?

- It takes much time to find the desired tool on Palette, because the list is so long. Expanding each section to find the tool is very inefficient. So my idea is providing an search box in Palette, user can input some keyword, then a list of tool are suggested. But I don't know what is the starting point to do this.
Does Sirius Palette extends GMF Palette? Or there are no Palette change in Sirius?
I search this extension point "org.eclipse.gmf.runtime.diagram.ui.paletteProviders" but there are no result in Sirius. Should I directly extend this extension point? But I worry about there are much effort to do searching function from the scratch. Please recommend me if there are any better way, or at least the starting point to do this.

Thanks in advance.

[Updated on: Mon, 08 June 2015 11:15]

Report message to a moderator

Re: Too many tools and sections in Palette, make slow Node creation and search [message #1697769 is a reply to message #1697621] Mon, 08 June 2015 11:03 Go to previous messageGo to next message
Le Chau Nguyen is currently offline Le Chau NguyenFriend
Messages: 19
Registered: August 2012
Junior Member
UPDATE:
My model like this: https://flic.kr/p/ukmtLi

Actually there are 316 hundred Club subclasses under Club class.
I used EMF to generate model code, includes SchoolImpl.java, FootballClubImpl.java etc...
By JProfiler, I see this function is executed 816 times when I place any sub Club Class to Canvas: SchoolImpl.eGet(int featureID, boolean resolve, boolean coreType).
Each function call take 2ms --> So it take at least 1.6 seconds for total 816 function call. And maybe it still takes some more seconds at others calls but I have not found them yet.

I think there are some validation for all Club sub classes were made, so it causes these large number of function call. But I can not find these validation yet.
Can anyone recommend me the generated code or validation code that I should modify to reduce the above function call number?
I am still stuck in this issue and really need your help.

[Updated on: Mon, 08 June 2015 11:04]

Report message to a moderator

Re: Too many tools and sections in Palette, make slow Node creation and search [message #1697786 is a reply to message #1697769] Mon, 08 June 2015 13:20 Go to previous messageGo to next message
Steve Monnier is currently offline Steve MonnierFriend
Messages: 572
Registered: May 2011
Senior Member
Hello,

Before trying to extend anything, maybe you can reorganise some Mappings
and Tools in your VSM (odesign file).
Among your 400 (or 316) Node Mapping (How big is your metamodel???),
maybe you can factorise a lot of your mapping by using an Abstract
Domain class? Also, you may be able to factorise a lot of mappings by
using some conditional style. The fewer mappings you will have, the
fewer tools you will need.
Among your tools, maybe you can factorise some of them by having
different task depending on the context. You can use an "if" task to
have different kind of execution.
Some of your tools could be removed from the palette and access via the
contextual action/menu (right click). You can create such contextual
action by using the tool "Operation Action". You can also group these
contextual action in a contextual menu by using the tool "Popup menu".
You can find information about these tools[1] on the online documentation.
Finally, If you have a few hundred mapping, even before the issue of
having 24 sections in the palette, I guess that the diagram is not
really readable if you have to show everything. I think that you can
reorganise your mappings and tools by using different layers. This way
the users select only the layers of usefull information in their context
and will only have the concerning tools in the palette.

Regards,
Steve

[1]
https://www.eclipse.org/sirius/doc/specifier/diagrams/Diagrams.html#tools_reference

Le 08/06/2015 13:03, Le Chau Nguyen a écrit :
> UPDATE: My model like this:
>
>
>
> Actually there are 316 hundred Club subclasses under Club class.
> I used EMF to generate model code, includes SchoolImpl.java,
> FootballClubImpl.java etc...
> By JProfiler, I see this function is executed 816 times when I place
> any sub Club Class to Canvas: SchoolImpl.eGet(int featureID, boolean
> resolve, boolean coreType). Each function call take 2ms --> So it take
> at least 1.6 seconds for total 816 function call. And maybe it still
> takes some more seconds at others calls but I have not found them yet.
>
> I think there are some validation for all Club sub classes were made,
> so it causes these large number of function call. But I can not find
> these validation yet.
> Can anyone recommend me the generated code or validation code that I
> should modify to reduce the above function call number? I am still stuck
> in this issue and really need your help.
>
>


--
Steve Monnier - Obeo

Need professional services for Sirius?
http://www.obeodesigner.com/sirius


Steve Monnier - Obeo Canada
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
Re: Too many tools and sections in Palette, make slow Node creation and search [message #1697876 is a reply to message #1697786] Tue, 09 June 2015 10:10 Go to previous messageGo to next message
Le Chau Nguyen is currently offline Le Chau NguyenFriend
Messages: 19
Registered: August 2012
Junior Member
Re-organizing Mapping/Tool for 300-400 Nodes would takes lot of effort, I may need to change the Model for this.
But it's maybe still easier than extending Sirius or EMF/GMF. I will try the organizing first. Thanks for your suggestion.
Re: Too many tools and sections in Palette, make slow Node creation and search [message #1699280 is a reply to message #1697876] Tue, 23 June 2015 08:35 Go to previous messageGo to next message
Le Chau Nguyen is currently offline Le Chau NguyenFriend
Messages: 19
Registered: August 2012
Junior Member
I have moved almost of Node to Enum type.
For example: "Football Club" is no longer a EClass, but becomes a EEnum. The children of "Football Club" becomes its literals.
Then the performance is improved a lot, no delay as before. Thanks Steve for your suggestion!

But after applying the above solution, there is an issue that I am stuck for many days:
The Enum Literal doesn't have attribute, so I cannot get its value to display or process it. So, I add "EAnnotation" to the Literal, and store the information I need in EAnnotation Detail Entries.
Then I try to access the EAnnotation in Label Expression of a Node. But I cannot find any way to read it by Acceleo; I tried: clubType.getEnnotation('info'), clubType.info, clubType::info, clubType.getProperty('info') etc.
But no command returns the value, except of clubType.toString(), it just returns the Literal name.
So can any one tell me how to access EAnnotation? Thanks in advance.
Re: Too many tools and sections in Palette, make slow Node creation and search [message #1699289 is a reply to message #1699280] Tue, 23 June 2015 09:08 Go to previous messageGo to next message
Steve Monnier is currently offline Steve MonnierFriend
Messages: 572
Registered: May 2011
Senior Member
Hello,

I am not sure why the performance is improved by switching to
enumeration here. I guess that if you need an attribute here means that
this should better be an EClass. Anyway, I see among the expression you
tried that you noted "clubType.getEnnotation('info')". I do not know if
it is a typo, but the method name is getEAnnotation('info'). i tried to
use it on an ecore sample with an EAnnotation, using the interpretor
view and it worked fine. Note that the annotation name to look for is
case and space sensitive.

Regards,
Steve

Le 23/06/2015 10:35, Le Chau Nguyen a écrit :
> I have moved almost of Node to Enum type.
> For example: "Football Club" is no longer a EClass, but becomes a EEnum.
> The children of "Football Club" becomes its literals.
> Then the performance is improved a lot, no delay as before. Thanks Steve
> for your suggestion!
>
> But after applying the above solution, there is an issue that I am stuck
> for many days:
> The Enum Literal doesn't have attribute, so I cannot get its value to
> display or process it. So, I add "EAnnotation" to the Literal, and store
> the information I need in EAnnotation Detail Entries.
> Then I try to access the EAnnotation in Label Expression of a Node. But
> I cannot find any way to read it by Acceleo; I tried:
> clubType.getEnnotation('info'), clubType.info, clubType::info,
> clubType.getProperty('info') etc. But no command returns the value,
> except of clubType.toString(), it just returns the Literal name. So can
> any one tell me how to access EAnnotation? Thanks in advance.
>


--
Steve Monnier - Obeo

Need professional services for Sirius?
http://www.obeodesigner.com/sirius


Steve Monnier - Obeo Canada
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
Re: Too many tools and sections in Palette, make slow Node creation and search [message #1699321 is a reply to message #1699289] Tue, 23 June 2015 11:21 Go to previous messageGo to next message
Le Chau Nguyen is currently offline Le Chau NguyenFriend
Messages: 19
Registered: August 2012
Junior Member
Hi Steve,

Thanks for your supporting.
This chart can show more detail about the solution: https://flic.kr/p/v59tTi
( the old one: https://flic.kr/p/ukmtLi )
So 400 Tools on Palette for creating 400 Nodes is no longer need. Just 20 tool for creating the top-Nodes like FootballClub, DancingClub. Inside the top-Nodes, user specify the "clubType", there are 20 club Literals for each top-Node.

Sorry for my typo mistake, I used clubType.getEAnnotation('info').
In Label Expression, it is:
"[clubType.getEAnnotation('info').details->first().value/]"


The error I got is:
!ENTRY org.eclipse.acceleo.parser 4 0 2015-06-23 16:28:36.355
!MESSAGE Compilation error for expression [clubType.getEAnnotation('info').details->first().value/] : Cannot find operation (getEAnnotation(String)) for the type (FootballClubType)


Maybe EEnum type doesn't support getting EAnnotation like EClass?

And I worry this Acceleo command even can work but will return Enum level, like FootballClubType's EAnnotation, not Literal level like FootballClubType.USClub's EAnnotation.
Could you give me a hint to solve this problem? I lost much time for this Sad

[Updated on: Tue, 23 June 2015 12:39]

Report message to a moderator

Re: Too many tools and sections in Palette, make slow Node creation and search [message #1699405 is a reply to message #1699321] Wed, 24 June 2015 06:46 Go to previous messageGo to next message
Le Chau Nguyen is currently offline Le Chau NguyenFriend
Messages: 19
Registered: August 2012
Junior Member
[UPDATE]
Acceleo can get EAnnotation of EClass. I tried the query successfully in Acceleo Interpreter:
[ self.target.eClass().getEAnnotation('info').details->first().value/] 



But getting the EAnnotation of Attribute of the EClass still has difficulty:
[self.target.eGet('clubType').getEAnnotation('info').details->first().value/] 

-> Error query: cannot find operation (getEAnnotation(String)) for the type (OclAny)

[self.target.eGet('clubType').eClass().getEAnnotation('info').details->first().value/]

-> Return: invalid
Evaluation result: ERROR in (calloperation): (object is not an instance of declaring class)

That seems I have to cast the OclAny to something, for example "EClass" so it may has EAnnotation? but "filter(EClass)" doesn't work for me. Interpreter just suggest something like DAnalysis, DFeatureExtension, DValidable etc...

[UPDATE]
Tried to cast to corresponding class in my meta data
[self.target.eGet('clubType').oclAsType(club::FootballClubType).eClass().getEAnnotation('info').details->first().value/]

--> Return: EObject
It is just for experiment, I think it would return the EAnnotation of FootballClubType EEnum only, not EEnumLiteral of it as I expect. But even in this query test, still no EAnnotation of FootballClubType return.

Now I am investigating more. If you have any idea, please advise me...

[Updated on: Wed, 24 June 2015 09:30]

Report message to a moderator

Re: Too many tools and sections in Palette, make slow Node creation and search [message #1699449 is a reply to message #1699405] Wed, 24 June 2015 11:51 Go to previous messageGo to next message
Le Chau Nguyen is currently offline Le Chau NguyenFriend
Messages: 19
Registered: August 2012
Junior Member
In EMF, both "EENum" and "EClass" realizes the EModelElement interface that provide "getEAnnotation" operation.
So getEAnnotation is expected to work with EENum.

But I always see the result: "cannot find operation (getEAnnotation(String)) for the type (FootballClubType)", when using this query:
[self.target.eGet('clubType').oclAsType(Club::FootballClubType).getEAnnotation('info').details->first().value/]

FootballClubType is EENum, with EENumLiteral like USClub, JPClub etc.

That seems I have to give up and restart the model design from the scratch.
Re: Too many tools and sections in Palette, make slow Node creation and search [message #1699453 is a reply to message #1699449] Wed, 24 June 2015 12:17 Go to previous messageGo to next message
Steve Monnier is currently offline Steve MonnierFriend
Messages: 572
Registered: May 2011
Senior Member
Hello,

I would not have tried it with enumeration and annotation as it seems
overcomplicated compared to en EClass. I have the impression here that
there is a confusion between the information that is in the metamodel
and the one in the model (conform to the metamodel). Maybe this will be
easier using EClasses and EAttributes.

Regards,
Steve

Le 24/06/2015 13:51, Le Chau Nguyen a écrit :
> In EMF, both "EENum" and "EClass" realizes the EModelElement interface
> that provide "getEAnnotation" operation.
> So getEAnnotation is expected to work with EENum.
>
> But I always see the result: "cannot find operation
> (getEAnnotation(String)) for the type (FootballClubType)", when using
> this query:
> [self.target.eGet('clubType').oclAsType(Club::FootballClubType).getEAnnotation('info').details->first().value/]
>
> FootballClubType is EENum, with EENumLiteral like USClub, JPClub etc.
>
> That seems I have to give up and restart the model design from the scratch.
>


--
Steve Monnier - Obeo

Need professional services for Sirius?
http://www.obeodesigner.com/sirius


Steve Monnier - Obeo Canada
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
Re: Too many tools and sections in Palette, make slow Node creation and search [message #1699545 is a reply to message #1699453] Thu, 25 June 2015 01:36 Go to previous messageGo to next message
Le Chau Nguyen is currently offline Le Chau NguyenFriend
Messages: 19
Registered: August 2012
Junior Member
Thanks Steve for your answer.
I see my confusion between meta-model and the class conform the model.
FootballClubType conforms EENum but no way to climb to EENum like EClass by eClass().
So re-design the model to use EClasses as your suggestion is the only way.
Re: Too many tools and sections in Palette, make slow Node creation and search [message #1861579 is a reply to message #1699545] Thu, 19 October 2023 17:34 Go to previous messageGo to next message
Shin Chane is currently offline Shin ChaneFriend
Messages: 2
Registered: October 2023
Junior Member
I can see the challenges you're facing with a large number of tools in your Viewpoint Specification Design file. It's understandable that reducing the number isn't an option due to your specific requirements.

Regarding the slow node creation, it does seem like Sirius might be Tiempo Real performing some validations. To optimize this, you might want to consider extending a Sirius extension that controls the drop behavior. As for the specific extension, I'd recommend checking Sirius documentation or community forums for guidance.

For improving tool search efficiency in the Palette, implementing a search box sounds like a good idea. However, I'm not certain if Sirius Palette extends GMF Palette or if there have been any changes in Sirius regarding this. It might be best to consult the Sirius documentation or reach out to the community for advice on where to start.

Best of luck with your optimizations!




Re: Too many tools and sections in Palette, make slow Node creation and search [message #1866222 is a reply to message #1697621] Wed, 22 May 2024 18:36 Go to previous messageGo to next message
Thomas  Kaplan is currently offline Thomas KaplanFriend
Messages: 2
Registered: May 2024
Junior Member
The excessive number of tools and sections in the Palette can significantly slow down the process of Node creation and searching. This clutter makes it difficult to quickly locate and select the necessary tools, leading to inefficiencies and frustration. Simplifying the Palette by organizing tools into more intuitive categories or reducing the overall number of sections can streamline the workflow, making Node creation and search more efficient and user-friendly.





Re: Too many tools and sections in Palette, make slow Node creation and search [message #1866225 is a reply to message #1861579] Wed, 22 May 2024 18:38 Go to previous message
Thomas  Kaplan is currently offline Thomas KaplanFriend
Messages: 2
Registered: May 2024
Junior Member
The excessive number of tools and sections in the Palette can significantly slow down the process of Node creation and searching. This clutter makes it difficult to quickly locate and select the necessary tools, leading to inefficiencies and frustration. Simplifying the Palette by organizing tools into more intuitive categories or reducing the overall number of sections can streamline the workflow, making Node creation and search more efficient and user-friendly.





Previous Topic:List widget
Next Topic:Creating a graphical node after a selection is made on the selection wizard
Goto Forum:
  


Current Time: Thu Dec 12 23:52:02 GMT 2024

Powered by FUDForum. Page generated in 0.05278 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top