Bug 452662 - FilterListener is called twice
Summary: FilterListener is called twice
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Diagram (show other bugs)
Version: 2.0.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance, triaged
Depends on:
Blocks:
 
Reported: 2014-11-21 09:28 EST by Esteban DUGUEPEROUX CLA
Modified: 2016-04-11 08:04 EDT (History)
3 users (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 Esteban DUGUEPEROUX CLA 2014-11-21 09:28:52 EST 
With scenario of Bug 452558 FilterListener is called twice, even in manual refresh.
We could avoid that by having FilterListener execute its TriggerCommand only in manual refresh and in auto-refresh have it executed directly by the diagram refresh. We see in RefreshDiagramOnOpeningCommand that the same work of FilterListener is done, i.e. call of : 

CompositeFilterApplicationBuilder builder = new  CompositeFilterApplicationBuilder(diag);
builder.computeCompositeFilterApplications();
Comment 1 Esteban DUGUEPEROUX CLA 2014-11-21 09:58:47 EST 
The issue is that CompositeFilterApplicationBuilder is in diagram.ui plugin and has dependencies to NodeQuery which is dependant to draw2d.
A refactoring of this query is needed to be ui independant.
Comment 2 Pierre-Charles David CLA 2014-12-04 10:36:08 EST 
Is this issue about performance, or does it cause an actual bug to invoke the FilterListener? If this is a performance issue, please tag it as such and provide measurable data, see https://wiki.eclipse.org/Sirius/Bugzilla.

Without some actual explanation of why this is a problem and how bad it is, we have no way to prioritize the issue.
Comment 3 Esteban DUGUEPEROUX CLA 2014-12-05 04:28:19 EST 
This is about performance, using Test2.zip attachement of Bug 452558 with initial scenario we have these times :

FilteredElementsUpdateCommand execution : 4ms
DDiagramSynchronizer.refresh execution : 153ms
FilteredElementsUpdateCommand execution : 4ms

The cost of FilteredElementsUpdateCommand execution is minor but it should be executed only once at the end of diagram refresh execution.