Open Bug 1027978 Opened 10 years ago Updated 1 month ago

consider using bloom filter in querySelectorAll()

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

People

(Reporter: bkelly, Unassigned)

References

Details

Attachments

(1 file)

On twitter we had an interesting conversation with Brian Kardell.  He was asking if a bloom filter was used for querySelectorAll().

Boris indicated that while we use bloom filters in other places for CSS selectors, we don't currently use it for querySelectAll().  At the time it was implemented it was a net-negative in terms of performance.

However, Boris also suggests that the situation could have changed.  For example, we now have a selector cache in querySelectorAll().

He also mentioned that we need to be careful about measuring micro-benchmarks vs. real-world workloads.

Full twitter conversation is here:

  https://twitter.com/briankardell/status/479721371165929472
Spam Boris's request queue as requested. :-)
Flags: needinfo?(bzbarsky)
Attached file Microish benchmark
Some notes to self:

1)  Chrome (but not Safari) has some sort of optimization where if there is only one selector in the selector list and that selector has a descendant combinator where the LHS is an id selector then they do some sort of fast path.  That might be worth looking into, but is somewhat independent of this bug.

2)  We'd need to associate a hash with each selector in the selector list.  Probably want to factor out the code in RuleValue::CollectAncestorHashes.  An initial investigation can probably just recompute this on each qSA call, but long-term we want to cache it like we do the parsed selectors.

3)  Need to maintain the ancestor push/pop stuff as we walk over the tree.

4)  Need to check the filter; probably need to pass the hashes into nsCSSRuleProcessor::SelectorListMatches.
Another note to self: The steps in bug 1023445 might be interesting to measure.
Depends on: 1410624
Emilio will basically deal with this once he enable's stylo's code here.
Flags: needinfo?(bzbarsky)
Priority: -- → P3
Component: DOM → DOM: Core & HTML

Emilio, you fixed this in stylo, right?

Assignee: bzbarsky → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(emilio)

Kinda. We have optimizations for the kind of thing we use the bloom filter code like having ancestor selectors with class names and such.

We also have a code path where we match right-to-left, but I never managed to make it fast enough so right now it's not enabled.

So the situation is better but a bloom filter would probably still need measuring and could still be useful for the case we have multiple selectors and such.

Flags: needinfo?(emilio)
Severity: normal → S3

Nightly: 481000
Chrome: 5000

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: