Closed Bug 83834 Opened 23 years ago Closed 13 years ago

lazily compute SelectorMatchesData

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 598832
Future

People

(Reporter: dbaron, Unassigned)

Details

(Keywords: perf)

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.
Status: NEW → ASSIGNED
Keywords: perf
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
(...in bug 83482, I guess.)
Target Milestone: mozilla0.9.3 → Future
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).
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?
Assignee: dbaron → nobody
Status: ASSIGNED → NEW
QA Contact: ian → style-system
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.