1630442 - Slow loading and closing of reddit posts on Moto G (XT1031)

Status: REOPENED

(Core :: CSS Parsing and Computation, defect)

Description

[Asif Youssuff]

Basic information

Playing with a family member's old Moto G (XT1031) to get a better idea of how Fenix performs on the device and ran into some slowness while browsing the Firefox sub-reddit.

Steps to Reproduce:

1. Navigate to https://www.reddit.com/r/firefox/
2. Tap into a post - I used https://www.reddit.com/r/firefox/comments/g1q2j1/how_to_disable_video_autoplay_and_dont_conflict/ - this post had 6 comments at the time
3. Once loaded, tap the "x" on the right to close the post.

Expected Results:

Fast loading, but more importantly, fast closing.

Actual Results:

Sluggish opening, really slow closing (was unsure if I tapped the button).

---

More information

Profile URL: https://perfht.ml/2VabBjW

Basic systems configuration:

OS version: Android 5.1

GPU model: Adreno 305

Number of cores: Qualcomm Snapdragon 400 quad-core processor clocked at 1.2 GHz

Amount of memory (RAM): 1GB

Thanks so much for your help.

Comment 1

[Bas Schouten (:bas.schouten)]

We seem to see similar performance issues in Chrome. The Site JS uses a lot of time, there's nothing obviously wrong here except redditstatic.com just running a lot of JS. If you believe that Chrome is doing significantly better than us please do re-open!

Comment 2

[Asif Youssuff]

Bas, closing the post takes 4 seconds in Fenix, 2 or less in Kiwi (based on Chromium).

Tested using https://www.reddit.com/r/firefox/comments/g67zw7/firefox_devtools_ux_asks_how_do_you_use_the/

Comment 3

[Sean Feng [:sefeng]]

needinfo myself to collect more profiles on different phones for both Firefox and Chrome

Comment 4

[Daniel Holbert [:dholbert]]

Looks like we've got a 1.8 second style flush in the profile, followed by a ~600ms style flush. emilio, maybe you could take a look and see if it's anything obvious?
https://perfht.ml/3bfdAZ1
https://perfht.ml/2Lbuu03

There's also a long layout flush, which has flexbox in the stack, so that part might be a flexbox perf issue:
https://perfht.ml/2SQsfnc

Comment 5

[Daniel Holbert [:dholbert]]

(meant to ni emilio in previous comment)

Comment 6

[Emilio Cobos Álvarez (:emilio)]

The native stacks don't have symbols, which is a bit annoying and makes it hard to figure out what's going on :(

Asif, do you know if you had uBlock or similar extensions when you tested it? If so, does disabling it make it better? uBlock is known to cause some long styling times, but this is just a hunch.

Comment 7

[Asif Youssuff]

I honestly don't remember if I had uBlock enabled, so I removed it and profiled again. In another bug Jamie Nicol noted that screenshots can take a lot of time, so I disabled those this time.

I profiled opening and closing https://www.reddit.com/r/firefox/comments/gfjqo6/reddits_performance_is_crap_in_firefox/ from a link on https://www.reddit.com/r/firefox

Profile here: https://perfht.ml/3fy11vi

Hope it helps!

Comment 8

[Emilio Cobos Álvarez (:emilio)]

That looks like a fairly different profile... Native stacks are still broken :(

Markus, do you know why there are no symbols for such stacks?

Comment 9

[Rachel Tublitz [:rachel]]

S1 or S2 bugs needs an assignee - could you find someone for this bug?

Comment 10

[Daniel Holbert [:dholbert]]

Sorry, I marked this S2 but it's really probably better-categorized as S3, given that Chrome experiences similar issues. (per Bas's observation in comment 1, which matches my observations on my phone right now -- Chrome and Firefox feel similarly-janky).

(The reporter saw worse jank in Firefox vs. Chrome in comment 2, but Chrome still had a decent amount of jank. So this isn't an especially firefox-specific issue; hence, reducing severity-ranking a bit.)

Asif: would you mind retesting and seeing if you're still seeing a significant performance gap between Firefox and Chrome here? And if you are, would you mind capturing another profile?

I'm asking because: I tested this in Firefox Desktop in Responsive-Design-Mode, and I'm not seeing any particularly long time spent in flexbox layout -- I'm seeing a ~20ms flexbox-dominant reflow, rather than the >1s flexbox-dominant reflow that I had noticed in the last link from comment 4 (exerpted from Asif's original profile). So I'm wondering if the flexbox layout performance here has improved, e.g. via bug 1365806 perhaps [via addressing the scenario described in its dupe-bug 1503660].

Comment 11

[Asif Youssuff]

Daniel, I retested reddit on this device - thank you for following up.

I ran a few more tests - at best, Firefox is about equivalent, or a little less than a second slower. At worst, Firefox is still around 2 seconds slower. It is definitely worse at the closing aspect of my STR - Firefox is a lot closer in opening the post (within half a second to around a second). I am counting closing as the post is no longer seen, and the visible area where posts links are shown has stopped reflowing (no idea what is happening offscreen).

I took another profile - the profile shows me opening https://www.reddit.com/r/firefox/comments/ha0pud/is_it_finally_getting_updated/ from https://www.reddit.com/r/firefox/ and closing it from the close icon on the page.

https://share.firefox.dev/2BjNHL9

I lowered the interval to 10ms in response to profile requests in other bugs. Hope the profile is useful to you.

Thanks!

Comment 12

[Daniel Holbert [:dholbert]]

Thanks! That profile shows a ~137ms reflow for the "close" event (with nsFlexContainerFrame in the stack for most of it).

Here's the profile zoomed to the first large event processing delay, with the dark-blue-bar representing this 137ms reflow:
https://share.firefox.dev/2UUmYf7

A 137ms reflow is still not ideal, but I don't think it's the low-hanging fruit or necessarily unexpected here anymore, because:

• It's way down from comment 4 where we had a single 1299ms (~1.3 second) reflow. So this piece is 1/10th as bad as it was then.
• This reflow comes immediately after we spend approximately the same amount of time doing frame reconstruction (so it seems possible/likely that the reflow is just the cost of laying out all of those frames that were just constructed -- it's less likely to be us spinning our wheels re-laying-out the same content).
• This reflow is now a small fraction of the 3.4 second (3404ms) event-processing-delay that it's part of.

So: at this point, the largest obvious things to pursue in that period-of-jank are:

• the 264ms and 100ms restyle events.
• The time spent in JS/DOM (which is most of the time)

Reclassifying as CSS for now, for the restyles, but we may eventually want to kick this over to JS (and/or spin off a helper bug for the JS engine).

Comment 13

[Daniel Holbert [:dholbert]]

FWIW: it looks like the bulk of the Firefox Subreddit webpage's DOM gets detached from the document when you load a post, and it stays detached (it's detached forever?) even after you close the post. It looks like they regenerate an entirely new DOM, or something like that.

I determined this in devtools by:

• saving a reference to some node in the top-subreddit view, and confirming it has an intact parent-node-chain (i.e. testing its .parentNode, and that node's parentNode, etc.)
• then, I clicked a link to open a post, and checked the parent node chain of my saved node (and it had a null parent at some closer point now - I think its <div class="NavFrame"> ancestor had a null parent. So this indicated it had been detached from the DOM.)
• then I closed the post, and checked the parent node chain once more. It was still detached, and its <div class="NavFrame"> ancestor still had a null parent.

So: this isn't just a case of some nodes for the top-level-subreddit-page getting restyled to be hidden (or getting covered up by high-z-index foreground content) and then restyled to be shown again -- that sort of thing could conceivably be optimized to have fast layout/restyle. This seems to be entirely new nodes getting regenerated from scratch (and having to be styled/laid out from scratch) -- or something along those lines.

It's still possible that there are style/layout optimizations to be made here, but I think this has ruled out some of the obvious categories of places where we'd hypothetically be spinning our wheels doing unnecessary/redundant work.

Comment 14

[Sean Feng [:sefeng]]

I don't think we need to have more profiles for this bug...so I am removing my NeedInfo

Comment 15

[Markus Stange [:mstange]]

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

That looks like a fairly different profile... Native stacks are still broken :(

Markus, do you know why there are no symbols for such stacks?

I think the broken native stacks all end in libc.so, so this is probably bug 1529108.