Bug 481581 - Improve refresh behavior of BasicModelContentProvider to avoid performance problems due to needlessly repeated tree state restorations
Summary: Improve refresh behavior of BasicModelContentProvider to avoid performance pr...
Status: CLOSED WONTFIX
Alias: None
Product: Sphinx
Classification: Automotive
Component: Navigator & Editor Sockets (show other bugs)
Version: 0.10.0   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Stephan Eberle CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-06 07:40 EST by Stephan Eberle CLA
Modified: 2024-05-07 00:27 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Eberle CLA 2015-11-06 07:40:09 EST
= Problem description =

BasicModelContentProvider has multiple ResourceSetListenerImpls that trigger a refresh of the entire viewer or specific objects being displayed inside it in various situations that are/can not taken into account by EMF.Edit item providers (see #createResourceChangedListener(), #createResourceMovedListener(), #createCrossReferenceChangedListener(), and #createModelContentRootChangedListener() for details). In some situations however - in particular when the workbench is started - it can happen that several of there ResourceSetListenerImpls become active simultaneously and trigger many redundant refresh requests. Given that the current tree viewer state (expansion and selection) need to get recorded before and restored after every refresh request, the massive triggering of redundant refresh requests can become quite expensive.

= Proposed solution =

* Optimize the implementation of above mentioned ResourceSetListenerImpls and the subsequently invoked #refreshViewerOnXxx() methods to avoid redundantly triggered viewer refresh requests
* In particular, before triggering viewer refreshes for individual model objects, it should be checked if a refresh for the underlying resource or the entire viewer is already underway
* See also TODO/FIXME comments in the code for some additional ideas how this could be achieved
Comment 1 Stephan Eberle CLA 2016-01-20 05:37:18 EST
In a first step, the triggering viewer refreshes for every affected model object or resources has been eliminated by refactoring all BasicModelContentProvider#refreshViewerOnXxx() methods into dedicated XxxRefreshStrategy helper classes. They allow to perform bulk refreshes of all affected model objects or resources in a single step, and to ensure that the tree viewer state gets recorded and restored only a single time but not for every model object or resource separately.

In a still outstanding second step, the number of refreshes should be further optimized by reworking the ResourceSetListenerImpls mentioned in the description. They should actually be merged into a single ResourceSetListenerImpl to avoid that they evaluate the same change notification(s) independent of each other and trigger refreshes that are needless because one of the other ResourceSetListenerImpls has already triggered the same or a similar kind of refresh. See TODO comments in the BasicModelContentProvider code for further details.
Comment 2 Balazs Grill CLA 2024-05-07 00:27:42 EDT
Closed stale issue before migration