Closed Bug 1716989 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: Graphics: WebRender, defect)

Firefox 88
x86_64
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1716049
Tracking Status
firefox89 --- wontfix

People

(Reporter: hpj, Unassigned)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: perf, regression)

Attachments

(4 files)

Attached image Screenshot_20210614_123104.png (deleted) —

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.

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.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Also please attach your about:support page.
Thanks.

Hi Martin,

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

Thanks for the hint.

Flags: needinfo?(hpj)
Flags: needinfo?(hpj)
Attached file about:support (deleted) —

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.

Flags: needinfo?(hpj)

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

Flags: needinfo?(hpj)
Blocks: gtk-kde
Priority: -- → P3

(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.

Flags: needinfo?(hpj)

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?

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.

Flags: needinfo?(hpj)
Attached file ff88_about_config.json (deleted) —

Firefox 88 about:support

Flags: needinfo?(hpj)
Attached patch ff88-ff89_about_config.diff (deleted) — Splinter Review

Contains some interesting differences.

See "failures"

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                                                 |
+-----------------------------------------------------------------------------+

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.

"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?

Blocks: wr-nv-linux
Component: Widget: Gtk → Graphics: WebRender
Keywords: perf, regression
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

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

Priority: P3 → --

(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.. )

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

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.

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

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.

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

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

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.

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.

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

(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.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Regressed by: 1712135
Resolution: --- → DUPLICATE
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: