Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 363835

Summary: [Model Explorer] General Performance problems
Product: [Modeling] Papyrus Reporter: Tristan Faure <faure.tristan>
Component: CoreAssignee: Mathieu Velten <mathieu.velten>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P3 CC: cletavernier, eclipse-bugzilla, jacques.seronievivien, mathieu.velten, raphael.faudou, sebastien.gerard
Version: 0.10.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard: backport needed on trunk
Bug Depends on:    
Bug Blocks: 365112, 426360    

Description Tristan Faure CLA 2011-11-15 09:54:48 EST
The model explorer is particularly slow when a huge number of elements are leaves of a node. Can be interesting to use VRTUAL trees or Deferred content provider.

It is also slow when the synchronize option is enabled.
Comment 1 Sébastien Gérard CLA 2011-12-05 04:23:01 EST
Patrick,

I thin k you have done some work related this issue. please, could you comment this bug and close it if ok.

Thanks,
Sébastien.
Comment 2 Patrick Tessier CLA 2011-12-06 05:27:34 EST
I have worked on this bug about performance  Bug 364044.

Could you explained exactly what kind of performance problem you have?  a drop a move, expand a subtree?
Comment 3 Tristan Faure CLA 2011-12-12 09:56:59 EST
we will check it and come back to you
Comment 4 Mathieu Velten CLA 2011-12-21 09:27:31 EST
The speed of the synchronize option has been improved a lot.

Please see the commented code for more infos.

commited on branch 0.8, rev 6522, will be backported soon.
Comment 5 Mathieu Velten CLA 2012-08-16 11:24:59 EDT
We identified a really big problem regarding the perf of the model explorer : all the visible elements is refreshed multiple times (like 4-5 times) by calling the content provider when a single modification of the model is done.
This is because the global refresh of the viewer is called for each event received in resourceSetChanged :
the efficient way is to process the emf events received and only update the relevant elements.

This leads to really big improvements (4-5 times faster) when there is a lot of elements displayed.

This approach has been implemented in the 0.8.X-EYY branch (commited soon) and will be backported after some testing.

On a side note I had to hack EMF Facet to do that because getChildren on LinkItems is cached and is not refreshed if the model has changed. It could have been relatively easy to workaround because a factory exists to create LinkItem/ModelElementItem, unfortunately there is no proper way to override this factory, and all fields of relevant classes are private...

So currently my implementation use java reflection with setAccessible to modify private fields, which is more than ugly.
Comment 6 Mathieu Velten CLA 2012-08-27 11:01:06 EDT
bugfix of previous improvement : when using "enable write" on a read only resource the model explorer was not refreshed. Unfortunately there is no EMF event to catch when a resource go into writable mode so the refresh is manually launch after the enable write action.
Comment 7 Camille Letavernier CLA 2013-08-26 07:54:36 EDT
IsTableContainer and IsDiagramContainer queries performances have been improved in 767fe2bde06aad86789a9a5419665b59854e3580

- The scope of these queries has been reduced
- These queries do not rely on a CrossReferencer anymore

Pushed to master
Comment 8 Camille Letavernier CLA 2013-08-26 10:15:19 EDT
Not sure if this has been backported, but multiple refresh actions should not happen anymore: if multiple refresh are triggered for a single action, only one will be executed. See Bug 409472 for more details.

Moreover, optimizations described in Comment 7 greatly reduce the execution time of each refresh action.

I close this task.