Community
Participate
Working Groups
On windows, there is 30-50% performance regression in tests of org.eclipse.ui.tests.performance.presentations.PresentationCreateTest#*. Linux looks good. The regression seems to have got introduced around 6th January. There was a regression in December first but it got good on 4th January build. Hence, I initially thought it was noise but it has been consistent since then.
The problem caused by changes in SWT from v3718 to v3719. In particular, the test seems to be affected by increased time in ToolItem.setImage(). The issue might have being a consequence of changes made for improved control orientation support, see bug 29779.
Created attachment 191936 [details] Patch to run UI editor test on Eclipse M5 - do not apply This is the patch I used to make UI tests from CVS Head run on Eclipse 3.7M5. The patch is large as it removes several tests (not relevant to this issue) that have compile errors on M4/M5. The patch also removes all but one tests from PresentationPerformanceTestSuite, leaving only the editor creation test for one presentation. This allows to concentrate on one test. The patch also increases number of parts created by the test to get somewhat more stable test results. The patch also removes some code not relevant form this issue from the test. Steps I used to reproduce: => Setup: - Use Eclipse 3.7M5 as a development envorinment - Check out "platform-ui-tests" module from CVS - Apply patch - I had to copy ivjperf.dll to the root of org.eclipse.test.performance to get time measurement - Run PresentationPerformanceTestSuite. Note "Elapsed Process" time and "CPU Time" fro "WorkbenchPresentationFactoryClassic editor creation" test => Change: - Check out SWT and replace version with v3718. - Re-run the test. Note time for the modified test goes down by about 50% - Replace SWT with version v3719 - Note the time goes back up to the original number. On my computer With SWT v3718: Elapsed Process: 2.71s (95% in [1.37s, 4.04s]) Measurable effect: 1.24s (2.3 SDs) (required sample size for an effect of 5% of mean: 254) Elapsed Process: 2.82s (95% in [1.46s, 4.19s]) Measurable effect: 1.26s (2.3 SDs) (required sample size for an effect of 5% of mean: 241) With SWT v3719: Elapsed Process: 4.49s (95% in [1.79s, 7.2s]) Measurable effect: 2.51s (2.3 SDs) (required sample size for an effect of 5% of mean: 375) CPU Time: 4.84s (95% in [1.83s, 7.85s]) Measurable effect: 2.8s (2.3 SDs) (required sample size for an effect of 5% of mean: 402)
(In reply to comment #1) > The issue might have being a consequence of changes made for improved control > orientation support, see bug 29779. interesting, I didn't see that coming. Ole, could yo please try something for me ? open org.eclipse.swt.internal.ImageList go to line # 53, you should see this code /* * Feature in Windows. The ILC_MIRROR flag only mirrors the images in the ImageList * when they are about to be drawn, and only if the layout of the graphic context is * mirrored. For that reason ILC_MIRROR always can be set. This also allows changing * the orientation of widgets without recreating its image lists. */ flags |= OS.ILC_MIRROR; please remove that last line and run the performance. -> that is the only line of code that changed for ToolItem#setImage from v3718 to v3719. -> that flag should only matter during paint, thus I don't see how it is impacting the performance of setImage.
(In reply to comment #3) > flags |= OS.ILC_MIRROR; > > please remove that last line and run the performance. Yep, that works for me: v3719 with ILC_MIRROR -> without: Elapsed Process: 4.05s -> 2.39s CPU Time: 4.06s -> 2.5s
Created attachment 192109 [details] patch This patch fixed the performance problem. But it breaks bug29779: a right-to-left control needs an image list with right-to-left support in the past we would only create image list with right-to-left for controls that were created with right-to-left with bug 29779, any control can be changed to right-to-left after it is created, so we started to create all image list wihs right-to-left support just in case: if the controls changes to rtl or ltr the image list never needs to change. the other solution is to recreate the image list when the orientation changes, sounds easy but it is a lot of code todo (but I think it is possible).
Fixed in HEAD Oleg, please let me know if the tests are okay
File Bug 341282 to track the bug this fix introduced for bidi.
