1805122 - React app performance improves dramatically when page is not visible

Status: RESOLVED INACTIVE

(Core :: Performance: General, defect, P3)

Description

[vhzjb34pt]

Attachment: data.good.json

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

Go to https://frzyc.github.io/genshin-optimizer/#/setting
Upload the attached file
Go to https://frzyc.github.io/genshin-optimizer/#/characters/KamisatoAyaka/optimize and click "Generate Builds"

The app is currently built from https://github.com/frzyc/genshin-optimizer/tree/657e278ff5d8eeb2b22694026696bb121fbeef5c

see also: https://bugzilla.mozilla.org/show_bug.cgi?id=1762786

The app appears to be rerendering the whole page very frequently according to the React dev tools, but this doesnt cause cause issues in Chrome

Actual results:

The process is significantly faster when the tab is off screen

Expected results:

The process takes the same amount of time in either case
Chrome takes the same amount of time for both on and off screen

Comment 1

[Mayank Bansal]

With "8 threads" as the setting in the app :
tab in focus: https://share.firefox.dev/3Hpaple
tab out of focus: https://share.firefox.dev/3YiXwPx

It looks like if the tab is in focus, the DOM workers dont work (either they dont start, or work is not assigned to them or something). Alternately, it could be that there is some difference in implementation of DOM workers between the app and Firefox.

Edit: The same behaviour repros in a build from Jan-2020. So this is not a recent regression.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Thank you for the report and thank you Mayank for the profiles! Looking at the "tab in focus" profile at https://share.firefox.dev/3Hpaple it seems like indeed the problem is that react code is running for 250ms each time as a result of receiving a "message" event sent via a MessageChannel and this seems to be stalling the app from making forward progress. Note that I believe we're actually seeing 2 different types of postMessage runnables on that thread:

• "dom::PostMessageRunnable" marker label, corresponding to a mozilla::dom::PostMessageRunnable which is only used by MessageChannel/MessagePort. There are 28,811 samples with this runnable.
• mozilla::dom::MessageEventRunnable corresponding to a postMessage directly sent from the worker using DedicatedWorkerGlobalScope::postMessage. There are only 39 samples with this runnable because their durations are so short, but I believe these correspond to the message - marker table entries which do not have an associated "dom::PostMessageRunnable" label. The pattern seems to be that these come after the above runnables.

Filtering the marker table to "message" we can see that there actually seems to be a steady back and forth with the workers, as "Worker.postMessage" markers exist that indicate the page is sending a message to a worker, plus if we look at the marker table on a worker, we see it receives messages. The problem is just that the workers are doing like ~8ms of work for each message they receive, and the main thread is doing ~250ms and only sending out one new request, so effectively nothing is happening.

I wonder if the React DevTools could be involved themselves? That might explain the use of a MessageChannel? (Not that there couldn't be a MessageChannel in use between the page and the workers, it would just be slightly gratuitous and strictly less efficient. Unfortunately we don't have great introspection capabilities for that.)

Moving this to web-compat for now since this seems to be some potential combination of react and devtools and is not worker specific.

Comment 3

[vhzjb34pt]

Thanks for looking at this report!
It appears that the app creates central threadpool(workerpool?) in the main thread that coordinates work items to the worker threads. The main thread ends up starving the workers of work since it spends most of its time in rendering the page.

I can't find any mention of MessageChannel/MessagePort in the source repo so it probably comes from either React/React devtools or another dependency.
I'm not sure that React devtools is related though, since I can still reproduce the issue with it disabled

Comment 4

[Raul Bucata]

We appreciate your report. I was able to reproduce the issue.

Tested with:

Browser / Version: Firefox Nightly 111.0a1 (2023-01-27) (64-bit) / Chrome Version 109.0.5414.120 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome

Comment 5

[Sky Schubert [:skyschub]]

Nothing is broken, and it looks like React DevTools are also not involved, so there is nothing we can raise with them. I'll move this to the performance folks to see if they want to do something about it, or close this as WONTFIX if they don't.

Comment 6

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

This bug was moved into the Performance component.

:vhzjb34pt, could you make sure the following information is on this bug?

• For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Comment 7

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

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

For more information, please visit BugBot documentation.

Comment 8

[Frank Doty [:fdoty]]

Is this still an issue? If so can you please collect a fresh profile? With that information we can determine a path forward.

Comment 9

[Julien Wajsberg [:julienw]]

Hi reporter,
I wanted to have a look so I tried to reproduce myself, but I can't find the button "generate builds" at the moment.
Do the instructions need to be updated? Do you still see the problem on your side?
Thanks

Comment 10

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:fdoty, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit BugBot documentation.

Comment 11

[Frank Doty [:fdoty]]

With no answer from the reporter, we don’t have enough data to reproduce and/or fix this issue. Please reopen or file a new bug with more information if you see it again.