Community
Participate
Working Groups
I20060314-0800. Found this while tracking down degradation of "Activate 30 Java Editors" tests. The attached comparisons and hot spot listings show that with same amount of invocations Control.forceFocus() became considerably slower and let it appear near the top of the 3.2 hot spots.
Created attachment 36895 [details] Performance data
Here is a simple benchmark: import org.eclipse.swt.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class PR_133176 { public static void main(String[] args) { final Display display = new Display(); final Shell shell = new Shell(display); shell.setLayout(new FillLayout()); Tree tree = new Tree(shell, SWT.BORDER | SWT.CHECK); for (int i=0; i<270; i++) { TreeItem item = new TreeItem (tree, SWT.NONE); item.setText ("Item " + i); } Tree tree2 = new Tree(shell, SWT.BORDER | SWT.CHECK); for (int i=0; i<270; i++) { TreeItem item = new TreeItem (tree2, SWT.NONE); item.setText ("Item " + i); } shell.open(); long t0 = System.currentTimeMillis (); for (int i=0; i<100000; i++) { if (i % 2 == 0) { tree.forceFocus (); } else { tree2.forceFocus (); } } long t1 = System.currentTimeMillis (); System.out.println ("Time: " + (t1 - t0)); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Running the simple benchmark on 3.1 and 3.2 M6 (well, almost M6) gives the same results. Obviously, the benchmark is too simple and is not capturing what is happening. Are you able to recreate the slowdown every time?
>Are you able to recreate the slowdown every time? I made 4 measurements with different approaches and they showed the diff, but the scenario was more complex. The interesting part is that the invocation count was the same. I can repeat it tomorrow again but you might do the same using my scenario. My benchmark was to 1. install buildX 2. start fresh workspace 3. load jdt.text.tests + required plug-ins from repository 4. instrumented the ActivateEditorTest.measureActivateEditor so that it waits after the warm up phase (==> manually start profiler) and after the test (==> manually stop profiler) 5. started ActivateJavaEditorTest 6. started profiler when the test waited 7. stopped the profiler when the test waited The 'wait' was simply done by showing a dialog.
I would claim that focus was bouncing around but the number of invokations is the same. Let me know how you get on.
I found out that there was a driver problem on my machine. I reran the tests after fixing the driver and the forceFocus() no longer differed. Sorry for the noise.
No problem!
