Community
Participate
Working Groups
20040506 Linux GTK SN hacked SWT to print out whenever the UI-thread was took longer than 250ms to process an event on Windows and GTK. When we expand the packages view on GTK we are getting slow times processing the updates. STEPS 1) load org.eclipse.swt (CVS decorators are on, .classpath dance etc...) 2) Modify DecoratorManager with the followiung code Display.Z = true; l.labelProviderChanged(event); Display.Z = false; 3) Modify TreeViewer to do the following protected void doUpdateItem(final Item item, Object element) { // update icon and label IBaseLabelProvider baseProvider = getLabelProvider(); if (baseProvider instanceof IViewerLabelProvider) { IViewerLabelProvider provider = (IViewerLabelProvider)baseProvider; ViewerLabel updateLabel = new ViewerLabel(item.getText(), item.getImage()); if (Display.Z) System.out.println ("\t" + updateLabel); provider.updateLabel(updateLabel, element); if(updateLabel.hasNewImage()) if (!Display.Z) item.setImage(updateLabel.getImage()); if(updateLabel.hasNewText()) if (!Display.Z) item.setText(updateLabel.getText()); And then instrument the UIJob to display when times are long. We are getting about 450ms times on a 2.5 Ghz GTK box (which is not long but the machine is really fast). On Windows (also 2.5 Ghz), the decorator code doesn't come up. SN says, "The Display.Z hack was used to remove SWT from the equation."
*** Bug 62278 has been marked as a duplicate of this bug. ***
Here are some improvements we can make isExpandable is slow with anything with filters as we are doing getFilteredChildren(). We need to add a (private for now) hasFilteredChildren method to AbstractTreeViewer to see if we could optimize this. Right now updatePlus is about half as long as updateItem which is really not acceptable in the PackagesView as the filtering is quitre expensive.
The JavaCore has implement the hasChildren() method in more places, so this optimization should really help. To find out how much we gain, did you compare doing the same scenario with and without any filters?
I have released the optimization to HEAD and I will measure performance differences soon (need to get a couple more things sorted for M9 first).
Please verify that the released improvements have eliminated this problem?
Todd, I can show you where the hacks are to do this. Can't get to it right now.
I am getting 105ms on my laptop in 20040528 doing the same test. I am trying to get an 0506 workspace set up to double check but I am having some troble right now. I will mark as fixed and try to get a better comparison later.
Marking as closed.
