Community
Participate
Working Groups
I20060922-0010 Opening build.properties for a big plug-in locks the UI for 45+ seconds and heavily flashes the cursor beween busy and normal. - open /org.eclipse.jdt.ui.tests.refactoring/build.properties - go to 'Build' page Trace taken while blocked (looks like CheckboxTreeViewer creates children eagerly): "main" prio=6 tid=0x00280048 nid=0x6bec runnable [0x0007e000..0x0007fc40] at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:1883) at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:1321) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3340) at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:4889) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4059) at org.eclipse.swt.internal.win32.OS.SendMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.SendMessage(OS.java:2630) at org.eclipse.swt.widgets.Tree.createItem(Tree.java:1820) at org.eclipse.swt.widgets.TreeItem.<init>(TreeItem.java:195) at org.eclipse.swt.widgets.TreeItem.<init>(TreeItem.java:153) at org.eclipse.jface.viewers.TreeViewer.createNewRowPart(TreeViewer.java:932) at org.eclipse.jface.viewers.TreeViewer.newItem(TreeViewer.java:450) at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:796) at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:775) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:749) at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:774) at org.eclipse.jface.viewers.CheckboxTreeViewer.setCheckedChildren(CheckboxTreeViewer.java:404) at org.eclipse.jface.viewers.CheckboxTreeViewer.setCheckedChildren(CheckboxTreeViewer.java:412) at org.eclipse.jface.viewers.CheckboxTreeViewer.setCheckedChildren(CheckboxTreeViewer.java:412) at org.eclipse.jface.viewers.CheckboxTreeViewer.setSubtreeChecked(CheckboxTreeViewer.java:556) at org.eclipse.pde.internal.ui.editor.build.BuildContentsSection$4.run(BuildContentsSection.java:313) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) - locked <0x1b6f5798> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3367)
To be honest, I was never a fan of Build page solution for file output selection. I would prefer to see only the actual list of resources and be offered 'Add...' button to choose from the workbench resource chooser. However, it is possible that the fix for this problem can be done without the redesign - just removal of some bottlenecks.
The Binary Build and Source Build sections each have there own CheckboxTreeViewer. There is an initial update facility that sets the state of all checkboxes in the tree. This facility is executed on load for both trees in separate asynchronous threads. Performance Analysis: Test Machine: Windows XP - Service Pack 2 Intel Pentium M processor 1700 MHz 1.5 Gigs of RAM Test Run #1 SRC Performance (ms): 5687 BIN Performance (ms): 1232 Test Run #2 SRC Performance (ms): 5488 BIN Performance (ms): 1241 Test Run #3 SRC Performance (ms): 5507 BIN Performance (ms): 1232 Average: SRC Performance (ms): 5560 BIN Performance (ms): 1235 TOTAL Delay (s): ~ 7 Investigation into a more efficient algorithm will probably take more time then implementing Dejan's suggestion. Punting this bug over to our resident PDE usability and sexiness correspondent, Chris.
Ok, I'm going to start work on a redesign of this page as Dejan mentioned. I think we will simply list the entries in the build.properties instead of the whole file structure. I will add an Add/Remove button. Also, Dejan, what are your thoughts about some bubble widget usage here. For example, if you hover over an entry, say *.xml, you get a bubble widget with all the entries represented from the build entry?
Bubble widget is normally used to notify the user of some background-running event. I know that Google is osing it for hover information, but I would recommend against using it in this particular instance. Let's make a first pass with a plain list of entries and an 'Add...' button. Remove is typically not needed because we hook up 'Delete' key and pop-up menu for this function. There is a readily available resource chooser from the platform UI team, but we may have additional issues around wild cards.
Chris, is this the same bug as 138851?
*** Bug 138851 has been marked as a duplicate of this bug. ***
Mike, the layout stays as-is. Please determine this is a performance issue in the JFace CheckboxTreeViewer or if we are doing something inefficiently as clients. If it's a problem with the viewer, please move to the UI bucket and let us know if there is something we can do as a workaround
Brian, please get to the bottom of this.
It appears (as Markus guessed), that the problem resides with the size of a project. On my machine, it took an average of 4.5 seconds to bring up the build page in the Build Properties Editor. I found 100% of this time as spent in CheckboxTreeViewer.setSubtreeChecked(Object, boolean). I was able to elimiate about 600ms by removing a initializeCheckState() call in the createClient() function (we were initializing the tree twice). And when trying to fix the blinking of the cursor, I was able to stumble upon an extra 300-400ms. All in all, I was able to shave off 20% of the original time to open the editor (down to an average of 3.6 second on my machine). I would like to talk to Tod to see if we can further improve performance, but unfortunately the project's folder in which we are checking all the children contains 20,000+ files and 9,000+ folders. Modifications were made to BuildContentsSection v1.24
Brian, is this fixed or should we open/move a bug against platform/ui for the CheckboxTreeViewer.setSubtreeChecked(Object, boolean) problem?
We can move it to Platform UI, I am just not sure how much they can do. Currently, it is taking ~3.6 seconds to check 29,000+ objects. That is an average of .0001 seconds per checkbox. I am not sure how much more they can do to speed up the process of checking so many objects.
How about this, Markus, can you try to open the editor using tomorrow's I-Build? If the performance is not satisfactory, we can move the bug to Platform UI to see what they can do. I will still talk to Tod to see if he has any suggestions.
(In reply to comment #11) > We can move it to Platform UI, I am just not sure how much they can do. > Currently, it is taking ~3.6 seconds to check 29,000+ objects. That is an > average of .0001 seconds per checkbox. I am not sure how much more they can do > to speed up the process of checking so many objects. > IMO, as I said in my initial bug 138551, the problem comes more from the fact that the verification is done for the whole hierarchy while opening the build.properties file. This sounds not necessary as only root files are displayed in the editor and collapsed. I still think that this problem would completely disappear if the verification was done only on visible nodes... Is there any reason why this could not be done?
Frederic, I am not sure what you mean by 'verification'. Nothing is being verified. Nodes in the tree are being checked, and that is what is taking time. Brian, since the child nodes are not visible when the editor opens, it seems that it is a waste to spend that much time checking unvisible nodes. Please check with the platform/ui team to see what can be done there, e.g. lazily checking nodes.
(In reply to comment #14) > Frederic, I am not sure what you mean by 'verification'. Nothing is being > verified. Nodes in the tree are being checked, and that is what is taking > time. > Sorry, I just misinterpreted checking... :-(
In I20070403-1110, org.eclipse.jdt.ui.tests.refactoring/build.properties opens in about 4 seconds with busy cursor (no cursor flashing) but also without any progress indication. It's definitely better than before, but it's still a long time without feedback.
