Community
Participate
Working Groups
When opening a project, The ProblemsLabelDecorator fires a LabelProviderChangedEvent for all resources contained in this project. While in a ProblemTreeViewer, like the Package Explorer, this is handled in an optimized way by filtering out updates to resources which are not realized in the tree view, the Common Navigator has no such means. The result is that for a project with e.g. 50000 resources, a label update for 50000 elements is triggered even though the project is not even expanded in the view.
I think also the project explorer needs a mechanism to map resources to Java elements in a performant way.
(In reply to comment #1) > I think also the project explorer needs a mechanism to map resources to Java > elements in a performant way. > Can you elaborate on this?
All label provider changes from label decorators (CVS, error ticks) are communicated in terms of IResources changes, but viewers have to translate these to the real model elements (e.g. IJavaElements). The viewer will then send an 'update' to the model elements. This mapping is quite expensive and label provider changes are very frequent. Updating should also be done only for the elements that are really visible. The package explorer solves this by maintaining a IResource to element item map , that is kept up to date as items are created (mapped) and disponsed (unmap). Have a look at ProblemTreeViewer and ResourceToItemsMapper in org.eclipse.jdt.internal.ui.viewsupport to see what I mean.
Created attachment 116044 [details] Proposed "fix" In CDT we have kind of solved the scalability problem by a simple heuristic. If the number of changed resources is exceeds some magic constant (500), we simply trigger a full label refresh. This works quite nice. This patch implements the same strategy on CommonViewer level.
(In reply to comment #4) > Created an attachment (id=116044) [details] > Proposed "fix" > > In CDT we have kind of solved the scalability problem by a simple heuristic. > If the number of changed resources is exceeds some magic constant (500), we > simply trigger a full label refresh. This works quite nice. > This patch implements the same strategy on CommonViewer level. > I have briefly looked at the JDT classes suggested to Martin, and I think that's a cleaner and more promising way to solve this problem. For M5 I want to try to focus on the more major enhancements that affect the API/extension points, and this is a essentially a bug that can be fixed without API changes (probably), so I'm thinking of putting it off until M6. Is that OK, or are you desperate to have it sooner?
(In reply to comment #5) > I have briefly looked at the JDT classes suggested to Martin, and I think > that's a cleaner and more promising way to solve this problem. For M5 I want > to try to focus on the more major enhancements that affect the API/extension > points, and this is a essentially a bug that can be fixed without API changes > (probably), so I'm thinking of putting it off until M6. Is that OK, or are you > desperate to have it sooner? Thanks for looking into it. M6 is fine for me.
Released to HEAD 20090208
*** Bug 159828 has been marked as a duplicate of this bug. ***
