Community
Participate
Working Groups
Verifying performance results for all 3.6M4 scenarios, it appeared that the ProgressMonitorDialogPerformanceTest#testLongNames() tests lasts less than 5 milli-seconds on the windows perf test machines. This is not enough to have meaningful results. Strangely, the same test duration is around 100ms on the Linux machines which is correct...
Most likely not a regression. Time permitting.
This test belongs to org.eclipse.jface component...
This one is not for 3.6. Moving to 3.7
Created attachment 193734 [details] Patch The test was originally added for bug 207188. Changed test to measure multiple (30) text set calls on performance monitor dialog in multiple (20) groups. I added degradation comment as the test results will no longer be comparable with 3.6 and there is not much point to backport those test changes into 3.6. As a note, the GC.textExtent() is still called a lot: 250 times for the test string per each Dialog.shortenText() call. It originally tries to to remove chars 277 - 9724 but has to do ~250 iterations to arrive at the actual number of chars to be removed (27-9974). The real-life effects won't be as profound: few people will have 10K chars text on the progress dialog.
Patch applied to CVS Head.
Verified that the test duration in I20110424-2000 build is about 100ms - 150ms and that comparison results are properly grayed out.
(In reply to comment #4) Can this test be updated on the baseline too? I think that will be the ideal way rather than using a comment.
(In reply to comment #7) > (In reply to comment #4) > Can this test be updated on the baseline too? I think that will be the ideal > way rather than using a comment. No, existing baseline tests should never be changed, otherwise the baseline could not longer be considered as a stable reference... The only change allowed on baseline stream is to add a new test. So, the only solution in this case is to use a comment to gray the test result...
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #4) > > Can this test be updated on the baseline too? I think that will be the ideal > > way rather than using a comment. > > No, existing baseline tests should never be changed, otherwise the baseline > could not longer be considered as a stable reference... The only change allowed > on baseline stream is to add a new test. > > So, the only solution in this case is to use a comment to gray the test > result... I agree in principle but keeping a useless stable reference doesn't buy us much, hence I'd tend to fix the baseline.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #4) > > > Can this test be updated on the baseline too? I think that will be the ideal > > > way rather than using a comment. > > > > No, existing baseline tests should never be changed, otherwise the baseline > > could not longer be considered as a stable reference... The only change allowed > > on baseline stream is to add a new test. > > > > So, the only solution in this case is to use a comment to gray the test > > result... > > I agree in principle but keeping a useless stable reference doesn't buy us > much, hence I'd tend to fix the baseline. I you definitely think it's necessary, then do it. But be careful during the verification process as the tool has high probabilities to identify this test as not reliable because of its baseline instability (due to the big variation in the baseline test results history). If that was the case, this test would be removed from the current status and no regression could be detected on it...
To reduce confusion we could also delete the test and add it under a new name.
