Community
Participate
Working Groups
Build: 2.1 GA. The checkbox tree in question is on the 'Plug-ins and Fragments tab of the the runtime workbench configuration. This tree can potentially contain > 1000 elements, but it's only two levels deep. If I call the method setChecked(Object, boolean) a thousand times in a row, the operation takes ~30 seconds. Calling setCheckedelements(Object[], boolean) yields the exact same result. I'm guessing this method in turn calls setChecked(Object, boolean). Note that when I use a checkbox table viewer, as we do on the PDE > Target Platform page, calling CheckboxTableViewer.setChecked(Object, boolean) a thousand times takes ~ 1 second. CheckboxTreeViewer.setChecked() is thus definitely using an inefficient lookup algorithm.
Are you using setUseHashlookup(true) in both cases?
It tried it both ways, it made no difference.
Wassim, since you have a test case for this already set up, would you be able to step through it? I'm surprised by this, since findItem should find the corresponding TableTreeItem quickly due to the map lookup, and TableTreeItem.setChecked simply delegates to TableItem.setChecked, which should therefore have the same performance characteristics as as the CheckboxTableViewer scenario.
Nick, note that the problem that I'm having is with the "CheckboxTreeViewer", not "TableTreeViewer".
I just tested it this morning with 3.0M1 and with the setUseHashLookup(true) flag, and it worked like a charm. In the past when the setUseHashLookup(true) did not do make a difference, it could be that I inserted it at the wrong place (e.g. after the setInput(..) method was called). Thanks Nick.
setUseHashlookup() has: Assert.isTrue(getInput() == null, "Can only enable the hash look up before input has been set");//$NON-NLS-1$ So I don't think that could have been the case. Is it possible it wasn't getting set at all before?
It was there, but commented out. So I must have thought at some point that it was having no positive effect and there was no reason to keep it around.
