Perf comparison of creating large number of input type elements, and the perf of reloading page full of elements
Categories
(Core :: DOM: Forms, defect)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
(Depends on 3 open bugs)
Details
Attachments
(22 files)
17.78 KB,
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
|
Details | |
1.78 KB,
text/html
|
Details | |
1.62 KB,
text/html
|
Details | |
1.55 KB,
text/html
|
Details | |
1.24 KB,
text/html
|
Details | |
1.31 KB,
text/html
|
Details | |
1.34 KB,
text/html
|
Details | |
1.51 KB,
text/html
|
Details | |
1.56 KB,
text/html
|
Details | |
1.69 KB,
text/html
|
Details | |
1.15 KB,
text/html
|
Details | |
1.73 KB,
text/html
|
Details | |
1.85 KB,
text/html
|
Details | |
1.38 KB,
text/html
|
Details | |
1.53 KB,
text/html
|
Details | |
1.64 KB,
text/html
|
Details | |
1.27 KB,
text/html
|
Details | |
1.39 KB,
text/html
|
Details | |
1.36 KB,
text/html
|
Details | |
1.41 KB,
text/html
|
Details | |
1.53 KB,
text/html
|
Details | |
1.49 KB,
text/html
|
Details |
Spurred by bug 1939344 (and bug 1941140) and undeterred by bug 1942561 I am now profiling the following for all HTML Input Elements:
- Creating a page full of input elements and comparing it to Chrome
- Reloading a page full of input elements for all possible input element types
Emilio had found something worth fixing in the image loading testcase, showed some initial interest in looking at profiles and suggested that a comparison with Chrome would be useful.
Note that the comparison between Firefox and Chrome is only for generating the page. The "Reload" perf has not been compared - the idea being that for reload any extra work should be avoided regardless of perf difference.
All testcases were geenrated by chatpgpt, with only minor edits to remove extra styling.
cc emilio and dholbert.
Reporter | ||
Comment 1•22 days ago
|
||
Reporter | ||
Comment 2•22 days ago
|
||
Reporter | ||
Comment 3•22 days ago
|
||
Reporter | ||
Comment 4•22 days ago
|
||
Reporter | ||
Comment 5•22 days ago
|
||
Reporter | ||
Comment 6•22 days ago
|
||
Reporter | ||
Comment 7•22 days ago
|
||
Reporter | ||
Comment 8•22 days ago
|
||
Reporter | ||
Comment 9•22 days ago
|
||
Reporter | ||
Comment 10•22 days ago
|
||
Reporter | ||
Comment 11•22 days ago
|
||
Reporter | ||
Comment 12•22 days ago
|
||
Reporter | ||
Comment 13•22 days ago
|
||
Reporter | ||
Comment 14•22 days ago
|
||
Reporter | ||
Comment 15•22 days ago
|
||
Reporter | ||
Comment 16•22 days ago
|
||
Reporter | ||
Comment 17•22 days ago
|
||
Reporter | ||
Comment 18•22 days ago
|
||
Reporter | ||
Comment 19•22 days ago
|
||
Reporter | ||
Comment 20•22 days ago
|
||
Reporter | ||
Comment 21•22 days ago
|
||
Reporter | ||
Updated•22 days ago
|
Comment 22•22 days ago
|
||
I think those dependencies are the most problematic, thanks for doing this.
Comment 24•21 days ago
|
||
The ones using UAWidgets (date and such) aren't very surprising. UAWidget setup is very slow. Luckily those elements are such that pages rarely have many of them.
Reporter | ||
Comment 25•21 days ago
|
||
The perf difference of creating 5000 video elements is bad. By whatever magic, 5000 video elements are visible in Chrome in 1.2 seconds. We take 21s for the elements to appear.
nightly: https://share.firefox.dev/4hubYgE (21s+ 11s)
Chrome: https://share.firefox.dev/4aunyps (all video element visible after 1.2 seconds!)
Comment 26•21 days ago
•
|
||
Could you file a separate bug for that. Looks like UAWidget for video element is flushing style and whatnot.
Reporter | ||
Comment 27•21 days ago
|
||
(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #26)
Could you file a separate bug for that. Looks like UAWidget for video element is flushing style and whatnot.
Filed bug 1943629
Reporter | ||
Updated•20 days ago
|
Reporter | ||
Updated•19 days ago
|
Description
•