Community
Participate
Working Groups
Could you tell me whether changes went into SWT regarding layout behaviour on linux that would slow down resize (i.e. layout) performance by almost one half. Please see the following performance test. http://fullmoon.ottawa.ibm.com/downloads/drops/S-3.1M6-200504011645/performance/linux/org.eclipse.ui.tests.performance.WindowResizeTest.testWindowResize_org.eclipse.ui.resourcePerspective().html#CPU%20Time Here is a snippit of code from the test: int w1 = 300; int h1 = 400; int w2 = 1000; int h2 = 700; int currentW = w1; int currentH = h1; boolean setSize1 = true; for (int i = 0; i < 20; i++) { processEvents(); if (setSize1) { currentW = w1; currentH = h1; } else { currentW = w2; currentH = h2; } setSize1 = !setSize1; startMeasuring(); processEvents(); shell.setSize(currentW, currentH); processEvents(); stopMeasuring(); } commitMeasurements(); assertPerformance();
I guess we are talking about GTK here - adjust OS accordingly. What kind of layout are you using? What children are in the shell. Nothing has changed in the way layouts are done (plus this code is platform independant so you would expect to see a similar slowdown on Windows) but there may have been changes to the way widgets respond to resizes in general on GTK.
I thought you might find it interesting to see the build date where it changes I20050125, agree that there appear to be no equivalent jumps on the windows version of this test (see link). This test resizes the while workbench so the types of layouts used are many, but most likely GridLayout as well as one TrimLayout (UI class) + others.
Fall out from all the playing with setBounds() on GTK? Billy and SN to investigate, hauling in SSQ as necessary. I suspect getClientArea().
FYI - The typical workbench window uses only TrimLayout and FillLayout. GridLayout is used extensively in Wizards and the Preference pages but not the main workbench area.
I downloaded 3.1M4 with the tests from M4 and 3.1M5a with the tests from M5a. As far as I can tell, the code for the test itself has not changed. I cannot reproduce the slowdown shown by the test framework though: on my machine, 3.1M5a is 20% faster than 3.1M4 when comparing the CPU time. I am running on FC3 with GTK+ 2.4.14. I will try again on RHEL3 which should more closely match the test machine.
3.1M5 is also about 15% faster than 3.1M4 on my machine when running under RHEL3. I cannot explain the results from the performance test machine.
Here's billys setup of projects for testing this, I am going to try on my RH machine 3.1M4: org.eclipse.test v20041208 org.eclipse.test.performance v20041123 org.eclipse.ui.tests v20041216-0010 3.1M5a: org.eclipse.test v20050110 org.eclipse.test.performance v20050104 org.eclipse.ui.tests v20050218-1200
For M5a, I also needed to get org.eclipse.core.tests.harness v20050215a
I get the following results (for CPU time in ms) running the test 3 times: M4 - 86 89 88 M5a - 84 77 83 NOTE: for M5a, initially the setup was running as an application (i.e. RCP) and not a product this caused the perspective switcher to be under the main toolbar instead of on the top right and there was a lot less coolbar wrapping, Billy which way were you running M5a. Either way I think we need to go to the test machines now and find out whats fishy.
OK, found out what is happening, the screen saver was running on the machine before Jan 17, 2005 causing all UI type tests to be invalid. I'm closing this bug, will discuss with Releng how to resolve issues with bad test results pre Jan 25.
Before Jan 17 or after? Did the screen saver make the tests faster or slower ;-)?
Before Jan 17 the screen save was running, making the tests faster. After Jan 17, the screen saver was not running and we saw a slow down (%40) in the tests.
