Closed Bug 1524056 Opened 5 years ago Closed 3 years ago

Performance: Atrocious processing performance on news.google.com!

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Project Flags:
Performance Impact high
Tracking Flags:
Tracking Status
firefox65 --- affected
firefox66 --- affected
firefox67 --- affected

People

(Reporter: cconover, Unassigned)

References

Details

(Keywords: perf:pageload, Whiteboard: [f72][layout:backlog:78])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Updated to recent build of Firefox (67), (re-)tested loading a show-all stories on topic link of news.google.com which had previously been 2x slower than Chrome.

https://news.google.com/stories/CAAqOQgKIjNDQklTSURvSmMzUnZjbmt0TXpZd1NoTUtFUWlDb3BqRmpZQU1FYjN4UUd4M1BLdkFLQUFQAQ?hl=en-US&gl=US&ceid=US%3Aen

Actual results:

With FF 67.0a1, according to the App Telemetry plugin on my 2012 Mac Mini, the processing time was in the order of 17s:

Redirect 0 0
App cache 1 0
DNS lookup 1 0
TCP connection 1 0
TCP request 32 136
TCP response 168 0
Processing 173 17639
onload event 17812 2

This compares with 3.x seconds for Chrome 71.0.3578.98

Redirect 0 0
App cache 7 0
DNS lookup 7 0
TCP connection 7 0
TCP request 17 92
TCP response 109 1772
Processing 114 3610
onload event 3724 0

Expected results:

FF, with its new fancy rendering engine, should not be more than 5x slower than Chrome.

Try it yourself!

Firefox lives and dies based on performance (well first is really not getting totally hacked but...) For 15 years, the perception has been that FF is slow. 57 was a huge step forward, but with issues like this (processing so slow it appears to be locked up), it really brings back into question whether or not FF can compete. In my humble opinion, FF's reputation really hangs on performance. Most people only use a small subset of features of any given product, but what everybody sees, is performance.

Hi, thanks for your contribution. Tested this issue on Mac OS 10.13.6 I5 Core, windows 10 and Ubuntu 16.04 - on several Firefox versions: nightly 67.0a1, beta 660b5 and release 65.0. On all cases the issue can be reproduced. If more tabs are opened the time of loading increases. A couple of screenshots are added in order to see the time processing. Mention that in other browser as Chris Conover said the time processing is much smaller even more tabs are loaded.
Can you provide me a performance profile ? because on all three machines tested are differences

Status: UNCONFIRMED → NEW
status-firefox65: --- → affected
status-firefox66: --- → affected
status-firefox67: --- → affected
Component: Untriaged → Performance
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → Desktop
Version: 67 Branch → Trunk
Whiteboard: [qf]
Depends on: 1526040

I'm tagging comment 3 as 'obsolete' so that it autocollapses (and since it's probably not needed, for now).

Here's a profile taken on my linux Thinkpad P50 laptop: https://perfht.ml/2RMJbr9

There are multiple 200-300ms reflows during pageload there that look pretty bad. They're in pretty deeply nested grid/flexbox layout.

Component: Performance → Layout
Whiteboard: [qf] → [qf:p1:pageload]

Here's a profile on my 2015 13" MBP:
https://perfht.ml/2ULMP6E

Yikes! cpearce's profile has a single 14-second reflow operation. (Really, a 14-second call to nsGridContainerFrame::Reflow).

Looking at that profile, it looks like the page has 7 layers of nested CSS Grids, and 6 layers of of nested flex containers. (with other elements interspersed between them)

We should dupe bug 1524375 to this one, or the other way around. Caching measuring grid reflows the same way we cache the flex ones may be worth it.

See Also: → 1524375
Priority: -- → P2
See Also: 1524375 →

BTW, looking at a profile I did, and a chrome profile, both run all the timeouts at the very, very end of the load. Firefox took ~8 seconds; chrome took ~4 - though chrome was visually complete far earlier than we were. So the timer-deferral stuff isn't hurting us here, and may be helping us slightly

Hi Mats – Can you please make some time to prioritize and investigate this? Sounds like Emilio's suggestion in comment 8 might be a good approach. But I'd be curious about the level-of-effort here.

Flags: needinfo?(mats)

Fwiw, I commented in the dupe: bug 1524375 comment 5.
A wild guess is that it's roughly the same amount of work as for Flexbox.
I probably won't get to this until Q2 at the earliest.

Flags: needinfo?(mats)

For a really good / bad example (Mueller Report)

https://news.google.com/stories/CAAqOQgKIjNDQklTSURvSmMzUnZjbmt0TXpZd1NoTUtFUWlpa1lEZmpZQU1FZU00NWNxRzF3dnFLQUFQAQ?hl=en-US&gl=US&ceid=US%3Aen

Redirect 0 0
App cache 2 0
DNS lookup 2 0
TCP connection 2 0
TCP request 22 90
TCP response 112 0
Processing 120 41384 <---- not good
onload event 41504 1

Safari was much better ~ couple seconds, << 41

https://perfht.ml/2Vw4rIr profile (on a high-end desktop). 50% of the CPU time is spent in some type of Reflow (2.5 of 5.5s of Web Content CPU). 13s to load in total, though it looks like over half of that was waiting for one googleusercontent load while idle

Daniel is likely right on why the reflow is so bad here

Whiteboard: [qf:p1:pageload] → [qf:p1:f72:pageload][layout:backlog:2019q4]
Whiteboard: [qf:p1:f72:pageload][layout:backlog:2019q4] → [f72:qf:p1:pageload][layout:backlog:2019q4]
Whiteboard: [f72:qf:p1:pageload][layout:backlog:2019q4] → [qf:p1:pageload:f72][layout:backlog:2019q4]
Whiteboard: [qf:p1:pageload:f72][layout:backlog:2019q4] → [f72][qf:p1:pageload][layout:backlog:2019q4]
Whiteboard: [f72][qf:p1:pageload][layout:backlog:2019q4] → [f72][qf:p1:pageload][layout:backlog:2020]
Whiteboard: [f72][qf:p1:pageload][layout:backlog:2020] → [f72][qf:p1:pageload][layout:backlog:78]

Now that we triage by severity, setting this bug's priority to P2 to represent near-term backlog status. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

See Also: → 1591366

Does the issue still persist? I collected a new profile on high-end laptop https://share.firefox.dev/2ZSW5dw, our reflows seems doing fine now, 30 - 40 ms.

In my re-testing, this is much, much better, feels the same as Chrome now. I don't see any mention of it being fixed -did Google just change their layout, or did someone fix this? Hopefully it is / will be fixed regardless, or it will just pop up again.

Still an issue. news.google.com hangs Firefox. The status bar says transferring data from www.gstatic.com but it is not an issue with www.gstatic.com. After a very long while it gets past that point then waits at stats.g.doubleclick.net.

anilnnair, can you use profiler.firefox.com (Firefox Platform as the setting) to collect a profile for the hangs?

Flags: needinfo?(anilnnair)

I think, I figured out how to do that. Here you go: https://share.firefox.dev/2WitRYq

Thanks - it looks like your profile shows a different piece of code hanging from what this bug was originally focused on, so I've spun off a new bug report to cover your issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1653064

See Also: → 1653064
Flags: needinfo?(anilnnair)

sefeng, can you clarify if that range is for things getting better vs. getting worse?

(I'm not sure it makes sense for bug 1617472's patches (the only things in the range you linked) to have any perf impact at all, positive or negative; though emilio can confirm.)

Flags: needinfo?(sefeng)

I meant to say that was the patch which made it better.

Flags: needinfo?(sefeng)

This issue seems resolved as per comment 19.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
No longer blocks: 1682686

Note, we had previously been using this as a "grid reflow is slow and needs optimizing" bug.

bug 1591366 now sort of serves that purpose (for the optimizations that we've currently thought of, at least).

Performance Impact: --- → P1
Keywords: perf:pageload
Whiteboard: [f72][qf:p1:pageload][layout:backlog:78] → [f72][layout:backlog:78]
You need to log in before you can comment on or make changes to this bug.