Used the parsed-selector cache even for invalid selectors

RESOLVED FIXED in mozilla28

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Tracking

unspecified
mozilla28
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

We want this because jQuery commonly passes those in (when consumers are using its selector extensions), and we'd like to avoid reparsing them.  What we can do is just cache a null selector and use null to indicate "invalid, throw".

On the testcase in bug 922048 this drops my times from about 1850ms to about 1650ms.
(Assignee)

Comment 1

5 years ago
Created attachment 824732 [details] [diff] [review]
Cache the "invalid selector" state in our parsed-selector cache as well when doing querySelector(All).
Attachment #824732 - Flags: review?(bugs)

Comment 2

5 years ago
Comment on attachment 824732 [details] [diff] [review]
Cache the "invalid selector" state in our parsed-selector cache as well when doing querySelector(All).


>+    } else if (!selectorList) {
>+      // This is the "only pseudo-element selectors" case, which is
>+      // not common, so just don't worry about caching it.  That way a
>+      // null cached value can always indicate an invalid selector.
>+      // Also don't try to do any matching, of course.
>+      return NS_OK;
Odd, but apparently http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsINode.cpp#2311 does that.
Attachment #824732 - Flags: review?(bugs) → review+

Comment 4

5 years ago
https://hg.mozilla.org/mozilla-central/rev/90ca96b3e198
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
You need to log in before you can comment on or make changes to this bug.