1804893 - >120% CPU load on https://web.arbeitsagentur.de/ausbildungssuche/ when scrolling through the page

Status: NEW

(Core :: Layout, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/109.0 ID:20221204094021

I got a report this morning that the following site is causing high CPU load (120% for the content process and 40% for the main process) for Firefox also when doing nothing on that page:

https://web.arbeitsagentur.de/ausbildungssuche/berufsausbildung-suche?sty=0&seite=0&atyp=101,109&uk=Bundesweit

Here are two profiles:

https://share.firefox.dev/3PfCFsd (lots of formatDate and formatText invocations)
https://share.firefox.dev/3Yb0xkP (only formatText invocation but twice now)

All these invocations of formatText and formatDate happen within a DOMIntersectionObserver callback.

With Chrome the results are similar, but in Safari the CPU load of the content process is only half of it.

Comment 1

[Dennis Schubert [:denschub]]

ni? myself, we can probably reach out to them. But imho, we should still check if there's something we can optimize. :)

Comment 2

[Mayank Bansal]

This page has a memory leak. If you keep the page in foreground, the memory keeps on increasing. All of that is in heap-unclassiffied.

Comment 3

[Mayank Bansal]

Attachment: memory-report.json.gz

look at webIsolated=https://arbeitsagentur.de (pid 85844)

Comment 4

[Mayank Bansal]

On Chrome, the page keeps on using CPU, but memory doesnt increase

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It seems that the increase of heap-unclassified memory is only temporary when immediately scrolling through the page or just waiting long enough (some minutes). Then all the allocated memory is getting GC'ed and memory usage looks fine again. As it looks like it's the IntersectionCallback and specifically the detectChanges method that is causing that behavior.

Here a profile when scrolling and waiting: https://share.firefox.dev/3YesKHG
Another profile when doing nothing: https://share.firefox.dev/3hn1Cp9

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Here is a new profile with Firefox 119 while scrolling on the page: https://share.firefox.dev/3PMiPHb

It shows a lot of time spent in get Element.clientWidth because it causes a lot of Style computation, maybe due flushing the layout? Emilio, maybe you could have a look if there is something wrong on our side as well?

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

We should actually update the bug's summary given that the website got an update since the bug was filed and the cause of the high CPU has now changed (as it looks like).

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Have you reported the issue to the site? This feels mostly a site issue.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #8)

Have you reported the issue to the site? This feels mostly a site issue.

Dennis was in contact with them, but we did not reach out to them for the changed behavior. Maybe we should do?

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:fdoty|on_leave, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #6)

Here is a new profile with Firefox 119 while scrolling on the page: https://share.firefox.dev/3PMiPHb

It shows a lot of time spent in get Element.clientWidth because it causes a lot of Style computation, maybe due flushing the layout? Emilio, maybe you could have a look if there is something wrong on our side as well?

Sorry I used the wrong email address for Emilio, and didn't notice that it changed.

Comment 12

[Emilio Cobos Álvarez [:emilio]]

The page changes a CSS variable on a container with tons of elements (--suchergebnis-top). Since it's inherited we need to propagate it to all elements inside.

Comment 13

[Dave Hunt [:davehunt] [he/him] ⌚BST]

The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: macOS
Websites affected: Rare
Resource impact: Some
[x] Able to reproduce locally

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

The page changes a CSS variable on a container with tons of elements (--suchergebnis-top). Since it's inherited we need to propagate it to all elements inside.

Thanks for taking a look. Not sure if something has changed on the page in the meantime but I see up to more than 200% CPU load these days. As such I've created a new profile: https://share.firefox.dev/3vmRu6z

I assume that we have to move this bug into Layout? If not which component would be best here?

Comment 15

[Emilio Cobos Álvarez [:emilio]]

That seems reasonable, but it's unclear what there is to fix here: They're doing a style change that needs to propagate to every element, and then reading it out with scrollX.

I just checked and Chromium also flushes when getting scrollX/Y: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/local_dom_window.cc;l=1619;drc=e878cf3b255d710d3674a3237e5c4c7cf549f613

Do you see similarly-high CPU usage on Chromium-based browsers?

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Do you see similarly-high CPU usage on Chromium-based browsers?

No, using Chrome 120.0.6099.129 for testing I only see a CPU load of about 60% for both the parent and the content process. That means it's roughly 1/3 of CPU load compared to Firefox these days.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:alaskanemily, could you have a look please?

For more information, please visit BugBot documentation.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #16)

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

Do you see similarly-high CPU usage on Chromium-based browsers?

No, using Chrome 120.0.6099.129 for testing I only see a CPU load of about 60% for both the parent and the content process. That means it's roughly 1/3 of CPU load compared to Firefox these days.

Hi Emilio. Anything else that you would like to know? Happy to provide those information if I can. Thanks.

Comment 19

[Emilio Cobos Álvarez [:emilio]]

No, using Chrome 120.0.6099.129 for testing I only see a CPU load of about 60% for both the parent and the content process. That means it's roughly 1/3 of CPU load compared to Firefox these days.

That can be explained by chrome not having parallel styling (and thus firefox using more than one core to do the bulk of the work here).