1503119 - A lot of time spent in query_selector

Status: NEW

(Core :: DOM: CSS Object Model, enhancement, P3)

Description

[Vicky Chin [:vchin]]

Profiling fashionbeans using the geckoview_example app shows that a lot of time is spent in query_selector.

Profile: http://bit.ly/2zlSFTl
Link: http://www.fashionbeans.com/article/coolest-menswear-stores-in-the-world 

I see a similar profile using Fennec Beta 63
http://bit.ly/2zgISNZ

Comment 1

[Cameron McCormack (:heycam)]

It's possible that bug 1497389, which just landed yesterday, will help with this.  Depending on what kinds of selectors are being passed to querySelector.  Can you test with a build containing that change?

Comment 2

[Vicky Chin [:vchin]]

Here's a new profile with a build containing the change. 
http://bit.ly/2zdFMdU

Comment 3

[Emilio Cobos Álvarez (:emilio)]

I can repro this (most of the time) with responsive design mode on desktop, as long as I disable content blocking for that page.

This is a profile taken with that setup where the same issue can be seem:

  http://bit.ly/2zemGEi

But looking at what causes this this is a tracker script doing some very stupid thing. It's calling querySelectorAll once per each node, which is... not great. This page also takes forever to load on Chrome desktop fwiw.

I can dig into what the tracker script is trying to do if you think it'd be helpful, but I think regardless Geckoview should have content blocking, is that tracked somewhere?

Comment 4

[Vicky Chin [:vchin]]

:snorp Does Geckoview have content blocking? I'm not sure what we currently decide to block or not.

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Vicky Chin [:vchin] from comment #4)
> :snorp Does Geckoview have content blocking? I'm not sure what we currently
> decide to block or not.

Yes, it supports it via a setting.

Comment 6

[Andrew Overholt [:overholt]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
> 
> But looking at what causes this this is a tracker script doing some very
> stupid thing. It's calling querySelectorAll once per each node, which is...
> not great.

Is there something we could do to rate limit these calls or something?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

I don't know how such a thing would look, we need to return _something_.

Comment 8

[Daniel Holbert [:dholbert]]

I'm categorizing this as "pageload" since it looks like (in comment 3's profile) the expensive chunk of querySelectorAll calls all happen before nsDocument::UnblockOnload is called.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

This page also takes forever to load on Chrome desktop fwiw.

Hmm, it loads pretty quickly in Chrome-on-Desktop for me. (in normal mode and in their RDM mode)

It also loads quickly in Firefox-Nightly-on-Destop (even with content blocking disabled).

The key place where I'm seeing a difference is:

• Firefox on Android (with no content blocking), which takes 4-5 seconds for our blue loading bar to stop animating on load & reload.
  ...vs:
• Chrome on Android, which takes 1-3 seconds for its blue loading bar to stop animating on load & reload.

I can dig into what the tracker script is trying to do if you think it'd be
helpful

Aside from getting content blocking enabled, I think most actionable thing we can do here would be to discover if there's a particular operation during the pageload here (whether in querySelector runtime, or something else) where Chrome is beating us perf-wise, and then see what we can do about closing that gap.