1480477 - Removing DOM children where positional pseudo-classes are involved is really slow.

Status: NEW

(Core :: CSS Parsing and Computation, defect, P2)

Description

[Emilio Cobos Álvarez (:emilio)]

Attachment: Testcase.

See the test-case. Change firstChild by lastChild to make it twice as fast.

That being said, we're still pretty slow even with that... Need to look at what other engines are doing.

See bugs related to bug 1443066 for another more fine-grained invalidation that would make this cheaper, maybe.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Repurposing because we're really slow even with that fixed... :(

Comment 2

[Daniel Holbert [:dholbert]]

[setting this to p1 since it seems important & to get it out of triage queue -- feel free to adjust if you think that's higher priority than is merited though.]

Comment 4

[Daniel Holbert [:dholbert]]

--> categorizing as "responsiveness", given that this was from a dynamic-adding/removing-elements part of a benchmark (bug 1443066). And bumping to qf:p2 since qf:p1 is now reserved for pageload.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

(Just putting it further up in the ni? queue, sorry for the spam)

Comment 6

[Emilio Cobos Álvarez (:emilio)]

So I don't think bug 1899597 is great long-term... For the purposes of :nth-* child, maybe we should try to defer invalidation until the next style flush... David, do you know if there's any :has() style invalidation correctness issue that we could hit?

In any case it seems we should at least coalesce the sibling walking (even if that means removing the SlowSelectorLaterSiblings stuff? not sure)

Comment 7

[David Shin[:dshin]]

My initial concern was :has(:nth-child(..)) pushing up the restyle root, but :emilio pointed out to me that we already do something similar to it here. At least, it seems viable to hook into that mechanism for :has(:nth-child(...)) upwards invalidation.

Invalidating in RestyleManager has been source of correctness/perf issues for :has() as well, so this seems worth a shot.