[Linux] Major elevation of CPU consumption after update to v31

[andyprough]

On any web page that has any type of animation (e.g. an animated gif) the SoftwareVsyncThread maxes one CPU, spinning on a futex (per strace output). It does so even while nothing is changing on the page. For instance, opening a single browser window with an animated gif, with image.animation_mode set to "none," so the image is not in fact changing, still leads to the 100% CPU problem. The moment you switch to a tab without any potentially animated elements, the problem goes away.

This may be something particular to your Linux distro setup. I just tested it on my Void Linux system, and with animated gif's running on gfycat.com I noticed a mild CPU elevation, but nowhere remotely close to 100%. On Distrowatch I similarly see mild cpu elevation with animation running in a couple of their ads.

[pubpub]

I would create a ticket in the tracker, but I don't believe I have access to that, so for now, I will post about any new developments in this forum.

the issue tracker is at https://repo.palemoon.org/MoonchildProd ... oon/issues
also, I don't know whether this issue belongs there or on https://repo.palemoon.org/MoonchildProd ... UXP/issues
I believe you can just register an account and open one on either of those.

[Moonchild]

Anything that isn't specifically for the front-end or application code most likely belongs in the UXP repository.

[Marcus]

I notice the higher CPU usage too, Xubuntu here.
It started with V30 and remains with V31.
It happens in general browsing, not only animated/heavily script pages.
@mbecroft may be right

This is clearly a bug or significant misfeature.

[andyprough]

I notice the higher CPU usage too, Xubuntu here.
It started with V30 and remains with V31.
It happens in general browsing, not only animated/heavily script pages.

Are you folks possibly running into the problem with the new Ubuntu mesa "crocus" driver that was discussed on this thread: viewtopic.php?f=65&t=28240&p=228230#p228230

Just wondering. On Void Linux, my cpu usage will sometimes reach as high as 30% for one core on a gif-heavy site, and on Trisquel Linux I'm staying at or below 26% on gif-heavy sites.

Edit: antiX Linux ranges from 10%-16% cpu after the first few seconds of loading a gif-heavy site.

[Moonchild]

If you feel comfortable building from source, maybe you can narrow the issue down to a specific commit in the UXP repo? Try bisecting from the 29/31 split to the current/latest

[0strodamus]

I'm observing about a steady 40% usage on one core after a few minutes of browsing (for me, it doesn't matter if browsing is on gif heavy sites or not) AFTER all tabs have been closed. In previous builds (and with the commits below backed out in the build I'm typing this from) CPU usage goes down to 0% on all cores after closing all tabs.

I was able to resolve the high CPU issue by reverse patching the following commits (ie patch -R -Np1 -i ./commit_XXX.patch):

Issue #21 - Remove Telemetry plumbing and fix build.
Issue #21 - Remove remaining telemetry structs, callers and flags.
Issue #21 - Remove Telemetry from Accessibility, EME and WebRTC
Issue #21 - Remove use counters telemetry
Issue #21 - Remove panning/tab animation performance measurements
Issue #21 - Remove unused telemetry build variables
Issue #21 - Remove telemetry from the front-end
Issue #21 - Remove telemetry from PopupNotifications.jsm
Issue #21 - Remove Telemetry accumulation/structures from toolkit js
Issue #21 - Remove Telemetry from Push and devtools
Issue #21 - Change MappedAttrParser to store its nsIPrincipal instead of nsSVGElement

I'm not sure which of these is the actual culprit. I'm also not sure if these commits can be individually reverted without the others. As an example, I initially tried to compile without backing out the last commit on this list, but the build failed. Any advice on how to narrow it down? Is the most likely cause the various xpcom/threads changes? Can those changes be reversed without any of the others, especially the others from that same commit?

[Moonraker]

Not certain if this relevant to anyone,
I found turning off the desktop compositor and conky helped with the browser cpu usage to a substantial degree.
I have used puppy linux and pale moon for many years and never really noticed any substantial cpu usage until the latest release and turning off the some of the desktop bling seemed to cure most of it.

[mr tribute]

I just tried the gtk2 version of the official tarball for v31.1.0.

With hardware acceleration CPU usage is about 0 % on empty tab
Without hardware acceleration CPU usage is about 15 % on empty tab (weak PC)

Something seems to be broken when hardware acceleration isn't enabled. This seems to be a regression compared to the v29 series.
I also had black artifacts when resizing the window. This isn't typical of gtk2. Gtk2 typically fills "empty space" with the same color as the window background color. This looks more polished.

Maybe 0stradamus managed to solve it:

I was able to resolve the high CPU issue by reverse patching the following commits (ie patch -R -Np1 -i ./commit_XXX.patch):

Issue #21 - Remove Telemetry plumbing and fix build.
Issue #21 - Remove remaining telemetry structs, callers and flags.
Issue #21 - Remove Telemetry from Accessibility, EME and WebRTC
Issue #21 - Remove use counters telemetry
Issue #21 - Remove panning/tab animation performance measurements
Issue #21 - Remove unused telemetry build variables
Issue #21 - Remove telemetry from the front-end
Issue #21 - Remove telemetry from PopupNotifications.jsm
Issue #21 - Remove Telemetry accumulation/structures from toolkit js
Issue #21 - Remove Telemetry from Push and devtools
Issue #21 - Change MappedAttrParser to store its nsIPrincipal instead of nsSVGElement

I'm not sure which of these is the actual culprit.

[Moonchild]

Well backing all that out isn't a solution, since I'd still like to remove all that telemetry plumbing as it does impact performance, but I can back it out and try to do it a third time from scratch if there's no way to narrow this down any further with what we have now

[mr tribute]

I know nothing about code, but isn't there a way to make changes for specific target platforms (Windows, Mac, Linux) in a multi-platform codebase such as Pale Moon?

That telemetry is a small price to pay for Linux users since it has probably been there since the last rebase from Firefox 52. And it might not be active as far as actually sending telemetry. It's just code that runs, taking a few CPU cycles and a little memory, but nowhere near what Linux users experience right now.

[andyprough]

That telemetry is a small price to pay for Linux users

I disagree, I have no such major elevation of cpu consumption on Linux. Adding back archaic telemetry code in order to fix a non-problem would not be a good solution for me.

[mr tribute]

That telemetry is a small price to pay for Linux users

I disagree, I have no such major elevation of cpu consumption on Linux. Adding back archaic telemetry code in order to fix a non-problem would not be a good solution for me.

I think Pale Moon should work correctly without hardware acceleration enabled. It could be considered the default state.

If you run Pale Moon without hardware acceleration enabled and don't have elevated CPU activity, then that's definitely interesting info that should be taken into consideration IMO.

[andyprough]

If you run Pale Moon without hardware acceleration enabled and don't have elevated CPU activity

The hardware acceleration toggle is off and I'm idling at 0%-2%. It's the official Pale Moon Linux binary version 31.1 on Void linux. Intel embedded graphics on a 4-year old i7.

[mr tribute]

If you run Pale Moon without hardware acceleration enabled and don't have elevated CPU activity

The hardware acceleration toggle is off and I'm idling at 0%-2%. It's the official Pale Moon Linux binary version 31.1 on Void linux. Intel embedded graphics on a 4-year old i7.

This was my (not yet stated) assumption. Some Pale Moon for Linux users brute force badly optimized code by using Intel Core i7 or AMD Ryzen CPUs.

I wanted to get this fixed because from my perspective this would basically be the end for Pale Moon on Linux. There is a need for a low end browser for Linux. Many systems have 2 - 4 GB of RAM and dual core or weak quad core CPUs, typically Celeron CPUs in older netbooks/laptops.

These systems may or may not support hardware acceleration. This is assuming that hardware acceleration fixes the problem on all systems, but there have been reports that say otherwise. For a low end system Pale Moon v29 seems to be the way to go currently.

It's up to other Pale Moon for Linux users to make some noise if they think Pale Moon for Linux matters. Maybe many Linux users have decent hardware - that is entirely possible. For me, part of the beauty of Linux (and Pale Moon) has been the ability to give new life to old but fully functional hardware.

[Marcus]

For me, part of the beauty of Linux (and Pale Moon) has been the ability to give new life to old but fully functional hardware.

This. I'm on the same boat.
And there must be many like us, on low end/old computers where Pale Moon's (and Linux) lightness is it's main strength.

[andyprough]

This was my (not yet stated) assumption. Some Pale Moon for Linux users brute force badly optimized code by using Intel Core i7 or AMD Ryzen CPUs.

I wanted to get this fixed because from my perspective this would basically be the end for Pale Moon on Linux. There is a need for a low end browser for Linux. Many systems have 2 - 4 GB of RAM and dual core or weak quad core CPUs, typically Celeron CPUs in older netbooks/laptops.

I've also got a couple of 12-year-old i3's on antiX Linux without high CPU.

But I don't disagree that it should run as well as possible on older Linux systems. I myself make distro respins for those old systems and try to extend their useful life.

I just don't like the idea of taking 2 steps forward with deleting old unused code only to take 3 steps back by putting it back in because of anecdotal reports of high CPU edge cases. Edge cases where no one knows if it might be related to kernel changes, changes in mesa, or simply users that are clinging onto broken and abandoned extensions for some reason.

Anyway, it's not up to me and I have nothing further to add, I'll be quiet now.

[Moonchild]

I just don't like the idea of taking 2 steps forward with deleting old unused code only to take 3 steps back by putting it back in because of anecdotal reports of high CPU edge cases. Edge cases where no one knows if it might be related to kernel changes, changes in mesa, or simply users that are clinging onto broken and abandoned extensions for some reason.

^ This.

Since it's absolutely impossible for me to do anything about this without needing more information as to where the issue comes from and why old code removal triggers it specifically on some Linux systems but not others, we need help from the people who are affected by it. As stated before I really don't want to back all that work out then having to redo it yet again, and still not knowing what caused it would likely reintroduce whatever it is, anyway, so we need to try and find the cause to fix it.

All the relevant commits to the tree are marked with issue 21, and GRE has more of a split out of the individual parts I tackled in my removal so maybe that provides more help to make test builds. So do bisection if possible, find the target commit/regression range. See if you can find out which parts of the removal in that commit cause the issue seen. I need at least a rough idea of which part of the code is causing the perceived performance loss.

[0strodamus]

I think it would be nice if another affected user could replicate my results by building without the telemetry commits to verify they are indeed the cause.

I have a test build queued up with Issue #1898 - Make sure that the sanity test stops running if necessary, (which AFAICT isn't tagged with Issue 21), but has me wondering if runaway sanity tests are causing the persistently high CPU usage when the browser is idle. If that doesn't help, I'll try building with a smaller subsection of the telemetry commits reverted.

I don't know what a bisection is, so the best I can do is apply or revert patches from git commits. Someone else will have to come forward to contribute that level of troubleshooting.

The argument blaming this on kernel changes, mesa changes, or broken and abandoned extensions is completely flawed. The only thing that changed on my system was the new browser build. I can downgrade to the previous build and the issue goes away. Install 31 and it's back, install 29 and it's gone. It's repeatable and consistent.

[Moonchild]

I don't know what a bisection is

https://en.wikipedia.org/wiki/Bisection ... gineering)

Basically, you keep splitting a range into two equal halves (see "bisect", bi = two, and sect from intersect) and check if something is fixed or broken, then taking the half that has your interest and doing it again.

e.g.:
say you have a range of 10 code changes (11 versions of the code starting at 0 (baseline, no code changes)), and something broke in commit 2 (v1-v2).
0--1--2--3--4--5--6--7--8--9--10
If you bisect, you start with version 5, and check if it's broken (yes)
this means it must be caused by commits 1-5, so you focus on that
0--1--2--3--4--5
You build version 3 (or 2, depending on what you prefer to split even numbers at; it doesn't matter), and check if it's broken (yes)
this means it has to be in the lower part again, so focus on that
0--1--2--3
Build v2, check (broken)
0--1--2
build v1, check (OK)
so now you know for sure it's commit 2 that caused it, after only 4 builds.

This becomes more efficient the more commits you're dealing with, because every doubling of the amount of commits only needs 1 more build.