Optimize incremental filtering and work around bug 1480477 in the new "about:config" page
Categories
(Toolkit :: Preferences, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: Paolo, Assigned: Paolo)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(5 files, 3 obsolete files)
Per bug 1523028 comment 44, we can improve performance either by changing how DOM nodes are removed or by avoiding ":nth-child". The latter could involve a design change or marking odd rows at table update time.
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•6 years ago
|
||
Depends on D19511
Assignee | ||
Comment 4•6 years ago
|
||
Depends on D19512
Assignee | ||
Comment 5•6 years ago
|
||
Depends on D19513
Assignee | ||
Comment 6•6 years ago
|
||
Depends on D19514
Assignee | ||
Comment 7•6 years ago
|
||
Depends on D19515
Assignee | ||
Comment 8•6 years ago
|
||
Depends on D19516
Assignee | ||
Comment 9•6 years ago
•
|
||
Here are some rough benchmark results. They are quite noisy, and may differ by a few milliseconds at each run.
I think the improvements we can notice with good confidence are for incremental filtering from Part 4 and Part 5:
Current: {bro:23.3, brow:17.8, brows:17.5, browse:17.3, browser:17.2}
Part 1+2: {bro:22.9, brow:17.7, brows:17.2, browse:17.1, browser:16.8}
Part 1+2+3: {bro:21.3, brow:17.4, brows:17.9, browse:17.6, browser:17.3}
Part 1+2+3+4: {bro:21.1, brow:15.3, brows:15.5, browse:15.5, browser:14.8}
Part 1+2+3+5: {bro:22.0, brow: 9.6, brows:10.5, browse: 9.9, browser:10.7}
Part 1+2+3+4+5: {bro:20.4, brow: 8.6, brows: 8.6, browse: 8.8, browser: 9.3}
Assignee | ||
Comment 10•6 years ago
|
||
Mike, Brian, see comment 9, I believe you weren't following the bug even though you reviewed the previous patch.
Assignee | ||
Comment 11•6 years ago
|
||
Since I already got r+ on the combined patch, I'm converting the reviews on the individual patches to a needinfo. We should determine if we still need this to support the perceived performance updates in bug 1527395, or if we can avoid the extra complexity.
Comment 12•6 years ago
|
||
It looks like 2 and 3 and arguably 1 don't end up buying us much here.
4 and 5 seem to be a pretty clear improvement.
Let's try just landing those for now.
Assignee | ||
Comment 13•6 years ago
|
||
Sorry for being unclear, part 2 and 3 are required to avoid regressions in part 5. This is because we try to change the class more often and in different combinations, and for each element in the table we would access the WeakMap, which is apparently slightly slower than using expando properties in this situation.
Comment 14•6 years ago
|
||
Huh, I see. Okay.
Well, I guess better land the stack then. Thanks.
Comment 15•6 years ago
|
||
Comment 16•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2660bdf28535
https://hg.mozilla.org/mozilla-central/rev/619f1112ed34
https://hg.mozilla.org/mozilla-central/rev/158ab30e6b96
https://hg.mozilla.org/mozilla-central/rev/c48000b1845f
https://hg.mozilla.org/mozilla-central/rev/a1a6fbcf6f35
Updated•6 years ago
|
Updated•6 years ago
|
Description
•