Community
Participate
Working Groups
Build ID: 3.4 Steps To Reproduce: I'm attaching some SWT snippets that we have used to measure some SWT operations. Some of the operations take significantly longer on some Linux platforms. The timings vary with XGL. I'm also attaching some spreadsheets with the results. More information:
Created attachment 105721 [details] Snippets used to test operations
Created attachment 105722 [details] PDF documenting results of the tests
We have your snippets running on my RHEL5 machine. We are trying to understand the results posted in your pdf file. What do the items in blue represent? What does "Calculate in Total" mean for the "With XGL Disabled" section? Which classes should we run to get the exact same results displayed in your table? Also, what hardware and memory are you running on?
Created attachment 105742 [details] Test computeSize add CalculateTest.java
I'll try to make the test results a bit clear. The 1st system is thinkpad T40 with 1.5 GB of memory. SLED SP2 not XGL enabled DrawTest create shell cost 155 create canvas cost 2 draw 10000 texts in total:4736 draw 10000 texts in total:2657 ResizeTest resize 100 canvas cost 15 resize 100 button cost 236 resize 100 label cost 34 WidgetCreateTest create 100 shell cost 336 create 100 canvas cost 40 create 100 button cost 134 create 100 label cost 209 XP DrawTest create shell cost 60 create canvas cost 0 draw 10000 texts in total:901 draw 10000 texts in total:892 ResizeTest resize 100 canvas cost 60 resize 100 button cost 70 resize 100 label cost 50 WidgetCreateTest create 100 shell cost 140 create 100 canvas cost 20 create 100 button cost 30 create 100 label cost 31 The second system we didn't run ResizeTest on it. It has 1GB memory and model of the processor is as follows: model name : Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz xgl disabled Sled 10 SP2 computeSize calculate in total:880 calculate in total:822 calculate in total:813 calculate in total:815 draw text create shell cost 216 create canvas cost 3 draw 10000 texts in total:1748 create widgets create 100 shell cost 456 create 100 canvas cost 63 create 100 button cost 139 create 100 label cost 117 Redhat 5.2 computesize calculate in total:1034 calculate in total:971 calculate in total:967 calculate in total:962 draw text create shell cost 42 create canvas cost 2 draw 10000 texts in total:2508 Create widgets create 100 shell cost 255 create 100 canvas cost 75 create 100 button cost 103 create 100 label cost 96 Window XP computesize calculate in total:687 calculate in total:625 calculate in total:609 calculate in total:609 draw test create shell cost 32 create canvas cost 0 draw 10000 texts in total:1390 create widgets create 100 shell cost 125 create 100 canvas cost 78 create 100 button cost 109 create 100 label cost 31 I attached the computesize test case and it is named CalculateTest.java. The other tests are attached in 1st zip file. Thanks, Steve
Hi Bogden, I wanted to check to see if I answered all of your questions and you have everything you need to take a look at this now? Thanks, Steve
I ran the tests on my dual boot machine (XP/RH5 - Intel Core 2 @ 2.33GHz, 1GB RAM). To be specific, I ran the DrawTest, ResizeTest, WidgetCreateTest and CalculateTest on both. Here are the results (averaged over 3 trials): DrawTest (first column XP, second column RH5) =============================================== * create shell: [31] [55] * create canvas: [0] [4] * draw 1000 rects: [31] [19] * draw 1000 text: [349] [1337] * draw 1000 palettes: [104] [29] * draw 1000 images (16,16): [5005] [13494] * draw 1000 images (52, 52): [7385] [20366] ResizeTest ========== * [7338 : XP] [37460 : RH5] WidgetCreateTest (first column XP, second column RH5) ====================================================== * create 100 shells: [119] [174] * create 100 canvas: [31] [29] * create 100 button: [68] [28] * create 100 label: [36] [26] CalculateTest (computeSize) ============================ * [515: XP] [690: RH5]
Here are some of our findings (running on our identical hardware): 1) After looking at the ResizeTest, we determined that it was really measuring Control.update(). After commenting out update(), on our hardware XP took around 5000 ms and GTK took around 1000 ms. Control.update() causes all outstanding paints to be delivered before update() returns. On X Windows systems, this is really expensive. So, resize() is not a problem but update() is. Unfortunately, we don't think there is much we can do about update(). Why and where are you calling update() in your code? We suggest not calling update(), if possible. 2) String draw has always been slower on GTK and is captured by bug 51693. We'd like to move the discussion there or enter a new bug report with the specific drawString() case you are seeing. 3) The Image draw benchmark includes the time taken for loading and disposing the image for each iteration. If we look at the actual time taken for drawing the image the actual times are: 16x16: 220 ms (XP) vs. 1399 ms (RH5) 52x52: 1200 ms (XP) vs. 1931 ms (RH5) We suggest that you break this benchmark into two parts: loading and drawing and enter bug reports for each. 4) Shell creation. On our hardware, the numbers were closer: 119 ms (XP) vs. 174 ms (RH5). We were able to improve shell creation on different hardware. If you want us to investigate further, please enter a new report with only the shell creation benchmark.
I'm not confident that we can do much about update() or string operations. Rather, it might be possible to avoid calling these operations in your code. So, once the specific bug reports are entered, I'd like to close this one and see what we can do about the various individual problems. Do you agree?
We fixed the shell creation problem. See Bug 238847 for details.
Steve (Best), we are waiting on your input in order to proceed. For example, if you break down some of your benchmarks into separate bug reports, we might be able to make progress on them in the same way we improved shell creation. In particular, image drawing might be able to be improved.
Steve Best, we are still waiting on individual benchmarks (if you still want to pursue them).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
