83834 - lazily compute SelectorMatchesData

Status: RESOLVED DUPLICATE of bug 598832

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

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think there may be some gains to be made from lazily computing the information
in SelectorMatchesData.  A number of the more expensive tests may not be used in
the typical case.  I should profile to figure out where we would gain here.

We currently (with my patches in bug ) spend about the same amount of time in
SelectorMatchesData::SelectorMatchesData as we do in SelectorMatches for opening
new browser windows, and much more time when loading CSSFrameConstructor in lxr.

When this is done we can add first-child, first-node, last-child, and last-node
information to the SelectorMatchesData.

Comment 1

[Hixie (not reading bugmail)]

(...in bug 83482, I guess.)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

cc:ing glazman.

Daniel:  If you ever want to implement :nth-child, :nth-of-type, etc., from the
CSS3 selectors draft, you should probably do this at the same time (at least to
have lazy computation for :[first/last]-[child/node] and the new ones added).

Comment 3

[Boris Zbarsky [:bzbarsky]]

So the idea here would be to move from accessing members directly to accessing
them with inline accessors, I assume?  And those would check whether the data
has been generated yet?