1716989 - Performance of 89.0 is almost unusable compared to 88.0.1 on openSUSE Tumbleweed/X11/KDE

Status: RESOLVED DUPLICATE of bug 1716049

(Core :: Graphics: WebRender, defect)

Description

[Hans-Peter Jansen]

Attachment: Screenshot_20210614_123104.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Upgrading Firefox 88.0.1 to 89.0 renders Firefox almost unusable in a HEAVY firefox setup, with many open windows and many open tabs in these windows.

After reverting and recovering the config from backup, things went back to normal (no reboot). The system is rather heavy equipped itself: Ryzen 9 3900X, 12 cores, 64G, NVidia GPU and driver. Tested with swap switched off as well.

openSUSE Tumbleweed 20210611, X11, KDE.

About any operation in the new FF appears delayed. Startup took a lot more than 10 times longer than usual. Other processes are running fine.

When switching between FF windows, a huge delay occurs (typically ~30 sec). During that time, one can see the Xorg.bin process is taking >90% of all cores.

It looks like something is serializing all X calls and probably the js engine, now.

Our maintainer switched from gcc to clang with 89.0, and disabled LTO in that process. Other than that, it's the usual package update churn: https://build.opensuse.org/request/show/897726

Actual results:

Just an example: given, a Jitsi meet window portal page is active.

Selecting a room in meet.opensuse.org takes 15 secs, enabling the camera 2, joining the selected room another 15, switching back to this window 15, during which the video frame rate drops to ~0.2 (eg. a new video frame every 5 secs).

Expected results:

With 88.0.1, everything is back to normal. switching between windows is instantly, and delays are down to what internet delivers in Germany as of today with a suitable connection.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Please try to disable WebRedner:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Check_WebRender
Thanks.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Also please attach your about:support page.
Thanks.

Comment 4

[Hans-Peter Jansen]

Hi Martin,

will (hopefully) be able to try in the next days.

Thanks for the hint.

Comment 5

[Hans-Peter Jansen]

Attachment: about:support

Comment 6

[Hans-Peter Jansen]

With gfx.webrender.all = true, the browser behaves a little better. Will keep it for the rest of the day, but I still see serious performance degradation.
Just opened https://linguee.de and, after the page is displayed, it took 15 sec. to process input. Something, that usually is instant for me.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Can you please try to catch the performance data with https://profiler.firefox.com/ ?
Also please attach your about:support.
Thanks.

Comment 8

[Hans-Peter Jansen]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

Can you please try to catch the performance data with https://profiler.firefox.com/ ?

Will do, but I wasn't able to keep 89.0 today (too heavy workload).

Also please attach your about:support.

Already done, look above.

Thanks.

Comment 9

[Hans-Peter Jansen]

Here's a profile with 89:
https://share.firefox.dev/3h88dzL
Most prominent is __poll from libc.so.6, hmm?
Given, that this FF is compiledd by clang, a lot of std operations reference __gnu_cxx, some mozilla libs perhaps?

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Looking at the profiler it seems to lag in NVIDIA binary drivers. See the "Renderer" line.

Is that a distro package or Mozilla binary?

If it's a distro package, please try Mozilla binary, see:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries
Thanks.

Comment 11

[Hans-Peter Jansen]

Attachment: ff88_about_config.json

Firefox 88 about:support

Comment 12

[Hans-Peter Jansen]

Attachment: ff88-ff89_about_config.diff

Contains some interesting differences.

See "failures"

Comment 13

[Hans-Peter Jansen]

Thanks Martin for your support.

Much appreciated.

I can check the upstream version over the weekend. for now, I would like to know, what's causing the difference to FF 88.0.2:

https://share.firefox.dev/3qzs3bl

Just enabled it for a 90 sec and it doesn't even provide a Renderer but the Compositor is active @ nearly 100% all the time.

Again, with 88.0.1, all behaves well.

The attached diff shows, that 89 enables the windowLayerManagerType WebRender, while it's Basic with 88.0.1, and suffers from it for some reason. See failures.

Will try to reproduce the 88.0.1 settings in 89.0.

BTW, I'm using a pretty low end NVidia GPU here:

Tue Jun 29 17:20:17 2021       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.84       Driver Version: 460.84       CUDA Version: 11.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  GeForce GTX 760     Off  | 00000000:0A:00.0 N/A |                  N/A |
| 43%   35C    P8    N/A /  N/A |    717MiB /  1996MiB |     N/A      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

Comment 14

[Martin Stránský [:stransky] (ni? me)]

As for the WebRender, you can try to set gfx.webrender.force-disabled to true at about:config (also set gfx.webrender.all and gfx.webrender.enabled to false). That will disable WebRender SW backend too and should switch you back to Basic. I think this is related to your gfx hardware and caused by WebRender.

Comment 15

[Darkspirit]

"numTotalWindows": 134,

Do you really have so many windows or is this a bug?

bug 1659848, bug 1667165: Having multiple windows when using OpenGL slows Firefox down on proprietary Nvidia: Even the tab dragging symbol seems to be a window that slows down the tab movement animation in the main window.

bug 1560457: Some users also need to disable "Sync to VBlank" somewhere and to enable "Force Full Composition Pipeline" in the Nvidia driver.

Do you observe the same problem with https://nightly.mozilla.org?

Comment 16

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

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 17

[Hans-Peter Jansen]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #14)

As for the WebRender, you can try to set gfx.webrender.force-disabled to true at about:config (also set gfx.webrender.all and gfx.webrender.enabled to false). That will disable WebRender SW backend too and should switch you back to Basic. I think this is related to your gfx hardware and caused by WebRender.

Will try that on weekend as well. My CPU is strong enough to handle everything with the CPU. Even with Jitsi and consorts.

(In reply to Darkspirit from comment #15)

"numTotalWindows": 134,

Do you really have so many windows or is this a bug?

Yes. No. Please call me a FF Power User with some pathological tendencies.

bug 1659848, bug 1667165: Having multiple windows when using OpenGL slows Firefox down on proprietary Nvidia: Even the tab dragging symbol seems to be a window that slows down the tab movement animation in the main window.

Will dive into these.

bug 1560457: Some users also need to disable "Sync to VBlank" somewhere and to enable "Force Full Composition Pipeline" in the Nvidia driver.

Will check.

Do you observe the same problem with https://nightly.mozilla.org?

I can try on the weekend. Like any other OOH screen worker, I heavily rely on FF during work days (and hate everything Chom... strong enough to keep it that way.. )

Comment 18

[Hans-Peter Jansen]

Julien, do you think, that this isn't worth a fix?

Comment 19

[Sören Hentzschel]

Julien, do you think, that this isn't worth a fix?

It was "wontfix'ed" for Firefox 89. Since Firefox 90 will be released in a few days it's clear that there will be no other update for Firefox 89. But this ticket is still open.

Comment 20

[Hans-Peter Jansen]

Ahh, good to know. Will wait for the next release and stick with 88 until then.

Comment 21

[Hans-Peter Jansen]

Just an update, I tried to enable webrender, but suffered from the same issues.

Using Martin's suggestions from https://bugzilla.mozilla.org/show_bug.cgi?id=1716989#c14 got it to behave.

Comment 22

[Hans-Peter Jansen]

Upps, sorry, hard day here, this is with FF 90 from our distribution now.

Comment 23

[Darkspirit]

Does this problem still occur? Can it be fixed by setting layout.frame_rate = 0?

Comment 24

[Hans-Peter Jansen]

Noticed your message https://bugzilla.mozilla.org/show_bug.cgi?id=1659848, but unfortunately, it doesn't correlate to final releases for me.
I'm on 91.0.2 here.

I will conduct some tests over the weekend (hopefully)!

Thanks for the hint.

Comment 25

[Hans-Peter Jansen]

I did now, with 92.0 - and behavior got worse: about half of my 24 (cpus: cores + threads) kept being busy - independent of gfx.webrender.{all,force-disabled} and layout.frame_rate setting.

With 91.0.2, Firefox starts with 15-30% cpu, and keep it for about a minute, then everything is settle at around 5% load. With 92.0, it starts with 5% raising to 40-50% after a couple of seconds, and keeping this load until closed (I went out for dinner, and on return (a couple of hours later), it still suffered from this load).

Reverting to 91.0.2 and restoring ~/.mozilla from backup got things back into a usable state.

Attempting to create a performance profile with 92.0 resulted in:

[Exception... "Out of Memory" nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" location: "JS frame :: https://profiler.firefox.com/537318bf7025e99b9787.bundle.js :: Dp :: line 157" data: no]

The full stack has been written to the Web Console.

Comment 26

[Darkspirit]

Does the same problem occur if you start Firefox with MOZ_X11_EGL=1 environment variable?
$ MOZ_X11_EGL=1 firefox

Comment 27

[Darkspirit]

(In reply to Hans-Peter Jansen from comment #0)

HEAVY firefox setup, with many open windows

If hardware rendering is enabled, one can't have many (OpenGL) windows on the proprietary Nvidia driver. Windows are blocking each other. The more windows you open, the less fps you get.

Workaround: Open about:config, set gfx.swap-interval.glx to false and restart Firefox.