1309181 - performance issues (lags, white area) when scrolling due to lots of time spent in nsStyleSet::FileRules

Status: REOPENED

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

Description

[Clemens Eisserer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161006105459

Steps to reproduce:

I have been trying to use Firefox on Android for the last couple of weeks now, and what frequently bothers me are performance issues when scrolling:

* Sometimes scroll events are lagging by a couple of 100ms, so  there is a noticeable delay between the scroll geasture and the actual scrolling

* When scrolling, the area I scroll to stays sometimes white for seconds, even dozens of seconds until Firefox is able to render the area currently visible. 

I was able to record the behavior on the following video: https://www.youtube.com/watch?v=KdmfgkGulSs

The phone used was a Nexus 5x (so a 2015 flagship device) which was lukewarm. The overlay graph shows the core frequency of the big (cortex-a57) cores - which were most of the time active but not at their peak frequency - so a rather real-world performance test. After testing Firefox, Chrome for Android was started which showed none of the mentioned issues and was responsive all the time.

Performance bugs like this one are critical in my opinion, as users don't care about the score their browser achives in sunspider/kraken/octane. Instead, they judge the performance of their browser when it comes to lag-free scrolling and real-world page load times.

Comment 1

[Clemens Eisserer]

additional remark: I've added the URL of the page used to demonstrate the issue in the video. However those performance problems are present in a wide variety of pages, sometimes more and sometimes less pronounced.

Comment 2

[u421692]

We've had a lot of scrolling issues since Firefox 48 due to the APZ feature. Most of the issues we're fixed.
However I was able to reproduce this on latest Nightly on Sony Xperia Z5 (Android 6.0.1), but it was already reported, see bug 1304689. It is assigned, and should be fixed in the near future.
Can you please check if you can reproduce this issue once that bug is fixed?
Thanks!

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I don't think this is the same as bug 1304689. It looks like here the main thread is just so bogged down that repainting is slow and the touch events are hitting the timeout before they can get processed. I can reproduce on my Z3C as well.

I'll try to get a profile of what's going on.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

So it seems like a large part of the problem on this page is that if the window is resized, it runs some long-running script (RecvContent.prototype.resizeCallback()) which hogs the main thread for a long time [1]. This is what results in the slow behaviour. The window gets resized because of the dynamic toolbar showing/hiding. So I turned off the dynamic toolbar (Settings -> General -> Full-screen browsing to false) and that helped quite a bit.

The responsiveness with that change applied is much better, but it still takes a long time to paint. Unfortunately the profile I got doesn't have symbol information [2] so it's hard to tell what exactly is taking so long.

[1] https://cleopatra.io/#report=cec6a36cd849e70747e7ecb37972d21fd6ab8762&selection=0,1,2,3,4,5,4,6,7,3,4,5,4,8,4,9,10,11
[2] https://cleopatra.io/#report=5cead8e81ff635034381756557d5f39a48f09fcc&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A592856,%22end%22%3A594133%7D%5D&selection=0,1,23

Comment 5

[Kartikaya Gupta (email:[e-mail])]

I used a local fennec build to get symbolicated profiles, and it seems like we're spending a lot of time in nsStyleSet::FileRules [1]. That function is called a lot by the JS code on the page, and accounts for 21% of the time while scrolling around. That being said, the RecvContent JS script on the page could probably be improved as well, as it seems to be doing a lot of stuff for no apparent reason (AFAICT it's used for the ads on the page).

Moving this bug over to the style system to see if this function can be improved. If not then we should probably see if the JS team can speed up execution of the script somehow, as the JS-related profile entries add up to a lot as well.


[1] https://cleopatra.io/#report=9d04c189e1ba517e5f43fe4060fb2279dc024745&invertCallback=true&selection=%22(total)%22,21,183

Comment 6

[Cameron McCormack (:heycam)]

Thanks for looking into Fennec's recent performance problems; I've noticed them (as a user) too.  I don't have any time currently to look into this, but:

Under FileRules is where we do selector matching when restyling an element.  I don't think we can easily make any improvments to how fast that process is (stylo should help here).  Instead we should work out why we're restyling and re-running selector matching so much.

Between the previous style flush and this one, we should look at what restyles we queue up (calls to RestyleManager::PostRestyleEvent) and why (e.g. are they due to an attribute value change, under RestyleManager::AttributeWillChange, and if so, what rules in the style sheet cause us to post this restyle).

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Is there a way I can build fennec with stylo enabled? I'd be curious to see if it makes a difference on perf here.

Comment 8

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> Is there a way I can build fennec with stylo enabled? I'd be curious to see
> if it makes a difference on perf here.

cc :bholley

Comment 9

[Bobby Holley (:bholley)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> Is there a way I can build fennec with stylo enabled? I'd be curious to see
> if it makes a difference on perf here.

Not yet, we're not targeting android for the first release (since we'll want to ship the old style system behind a pref, and codesize is a concern on android).

Comment 10

[Julien Cristau [:jcristau] (back April 22)]

Too late for firefox 52, mass-wontfix.