NEW87467
[Forms][PerfTest] Performance test for select element rendering
https://bugs.webkit.org/show_bug.cgi?id=87467
Summary [Forms][PerfTest] Performance test for select element rendering
yosin
Reported 2012-05-25 00:07:44 PDT
Rendering of select element is sometimes slow, such as BUG-87466, CR-90094. We would like to have perf test for select element to detect performance regression.
Attachments
Patch 1 (6.78 KB, patch)
2012-05-25 01:09 PDT, yosin
no flags
Patch 2 (18.96 KB, patch)
2012-05-25 03:04 PDT, yosin
rniwa: review-
rniwa: commit-queue-
yosin
Comment 1 2012-05-25 01:08:21 PDT
This bug is preparation for fixing BUG-87466.
yosin
Comment 2 2012-05-25 01:09:35 PDT
Ryosuke Niwa
Comment 3 2012-05-25 01:14:38 PDT
Comment on attachment 143997 [details] Patch 1 View in context: https://bugs.webkit.org/attachment.cgi?id=143997&action=review > PerformanceTests/ChangeLog:4 > + [Forms][PerfTest] Performance test for select element rendering > + https://bugs.webkit.org/show_bug.cgi?id=87467 Do we really need to add tests for this? Unlike layout tests, perf tests need to be ran sequentially and hence the cost of adding a new perf test is significantly higher than adding a new layout test. For example, each test that uses runPerSecond would run for at least 18s in total. Here, we're adding 90+ seconds to the perf bots' cycle time. I'm not sure how long these tests take to finish but we have to be careful not to add lots of micro benchmarks since we can write millions of micro benchmarks that won't matter much in practice.
yosin
Comment 4 2012-05-25 03:04:47 PDT
yosin
Comment 5 2012-05-25 03:12:10 PDT
Yes, we would like to have these perf test for avoiding regression of execution speed. It seems this performance regression is caused by re-factoring of HTMLOptGroupElement class. If we had had perf test at re-factor time, we could catch it before users saw. On my linux box (Z600), it takes 58 second to run 16 tests in this patch. Thanks.
yosin
Comment 6 2012-05-25 03:27:47 PDT
It is hard to guess that changing base class from HTMLFormControlElement to HTMLElement caused performance regression... :-<
Ryosuke Niwa
Comment 7 2012-05-25 09:28:17 PDT
(In reply to comment #5) > It seems this performance regression is caused by re-factoring of HTMLOptGroupElement class. If we had had perf test at re-factor time, we could catch it before users saw. > > On my linux box (Z600), it takes 58 second to run 16 tests in this patch. That means we're going to add 2-3 minutes if not 5 minutes on cr-mac perf bots since they're mac minis. That's not an acceptable amount of the cycle time increase for this feature. Performance tests aren't regression tests. We can't have 1,000 perf. tests. It doesn't scale.
Ryosuke Niwa
Comment 8 2012-05-25 10:34:47 PDT
I've talked with tony^work, kling, & anttik about this. I think everyone agrees with me that adding 16 tests for just rendering select element rendering is excessive. We could imagine adding other kinds of form elements and creating a form-control rendering test however. Also, popup menu, etc... uses completely different code path in DRT so I'm not even sure if these tests are testing what you're intending to test.
Ryosuke Niwa
Comment 9 2012-05-31 23:57:35 PDT
Comment on attachment 144023 [details] Patch 2 I don't think we want to land this patch as is.
Note You need to log in before you can comment on or make changes to this bug.