Bug 549484 - [PERFORMANCE] Optimization of semantic candidates evaluation
Summary: [PERFORMANCE] Optimization of semantic candidates evaluation
Status: UNCONFIRMED
Alias: None
Product: Sirius
Classification: Modeling
Component: Diagram (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows NT
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Anis KHARCHI CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2019-07-23 07:27 EDT by Anis KHARCHI CLA
Modified: 2019-07-24 11:39 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Anis KHARCHI CLA 2019-07-23 07:27:05 EDT 
-  defining semantic candidate expressions for non synchronized Mappings costs a lot more time than empty-semantic candidates.
-  guava list manipulation take 77% of time of the semantic candidates evaluation.
Comment 1 Eclipse Genie CLA 2019-07-23 08:19:42 EDT 
New Gerrit change created: https://git.eclipse.org/r/146500
Comment 2 Laurent Fasani CLA 2019-07-24 11:38:02 EDT 
Hello

It would be interesting to know what "the semantic candidates evaluation" represents in the total time of the refresh or the mapping computation to know at the end what the 77% represent in time. I saw the gerrit and I am just surprised that just filtering on EObject represents 77% of the "the semantic candidates evaluation" 

Did you test rewriting the filter with stream rather than guava?