WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
87467
[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
Details
Formatted Diff
Diff
Patch 2
(18.96 KB, patch)
2012-05-25 03:04 PDT
,
yosin
rniwa
: review-
rniwa
: commit-queue-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
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
Created
attachment 143997
[details]
Patch 1
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
Created
attachment 144023
[details]
Patch 2
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.
Top of Page
Format For Printing
XML
Clone This Bug