From Newsgroup: comp.sys.raspberry-pi

Just for amusement I've been trying to run the chromium browser
on a Pi2. Obviously, it's slow, but it looks like the cpu isn't
busy at all, mostly idle with a few percent for system processes.

Right now it's stuck loading a page from the New York Times
website. The Pi2 itself is responsive, but the chromium window
seems totally stuck.

Anybody else seeing this? I expected it to perform badly, but
not this badly.

I'm using the "universal" image of bookworm. Is an older image
likely to be better?

Thanks for reading,

bob prohaska





--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Wed, 09 Jul 2025 13:19:56 +0000, bp wrote:

Just for amusement I've been trying to run the chromium browser on a
Pi2. Obviously, it's slow, but it looks like the cpu isn't busy at all, mostly idle with a few percent for system processes.

Right now it's stuck loading a page from the New York Times website. The
Pi2 itself is responsive, but the chromium window seems totally stuck.

Anybody else seeing this? I expected it to perform badly, but not this
badly.

I'm using the "universal" image of bookworm. Is an older image likely to
be better?

Thanks for reading,

bob prohaska

Doesn't chromium render in GPU? And the Pi2 would have pretty basic specs/
low VRAM (or shared with system). So going to guess that's the reason?
Install a tool ("like" HTOP) but for monitoring GPU, that'll show it :)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

bp@www.zefox.net wrote:

Just for amusement I've been trying to run the chromium browser
on a Pi2. Obviously, it's slow, but it looks like the cpu isn't
busy at all, mostly idle with a few percent for system processes.

Right now it's stuck loading a page from the New York Times
website. The Pi2 itself is responsive, but the chromium window
seems totally stuck.

How much RAM do you have? Is it massively swapping to slow SD card?

If you're using htop, it won't show kernel threads unless you're press F2
for setup and then unselect Display options -> Hide kernel threads.

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 10/07/2025 00:02, Computer Nerd Kev wrote:

The odd thing is that I ran Firefox on x86 with 512MB RAM a
couple of years ago and it wasn't nearly as bad.

Have a look at the size of the executable "then" (which is more likely
to be 20 to 25 years ago) and now, and you'll see why a 512M Zero 2
doesn't stand a chance.

---druck
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 15/07/2025 21:17, druck wrote:

On 10/07/2025 00:02, Computer Nerd Kev wrote:

The odd thing is that I ran Firefox on x86 with 512MB RAM a
couple of years ago and it wasn't nearly as bad.

Have a look at the size of the executable "then" (which is more likely
to be 20 to 25 years ago) and now, and you'll see why a 512M Zero 2
doesn't stand a chance.

---druck

webkit webprocess is over 1GB on this machine now. Firefox process
another 800MB

Thunderbird another GB or so.
I buckled and now have 24G RAM.
--
The theory of Communism may be summed up in one sentence: Abolish all
private property.

Karl Marx


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

druck <news@druck.org.uk> wrote:

On 10/07/2025 00:02, Computer Nerd Kev wrote:

The odd thing is that I ran Firefox on x86 with 512MB RAM a
couple of years ago and it wasn't nearly as bad.

Have a look at the size of the executable "then" (which is more likely
to be 20 to 25 years ago)

No it really was only two or maybe three years ago and Firefox
wasn't that much bigger then.

and now, and you'll see why a 512M Zero 2 doesn't stand a chance.

The Executable still fits easily in 512MB RAM, for some reason it
tries to allocate lots more RAM after starting and displaying the
browser window (which seems to work fine for a few seconds before
it stalls).

It seems the RAM usage increased when they started using multiple
processes:

https://erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/

Maybe on the single-core x86 PC it creates fewer processes and
therefore uses less RAM than the quad-core Pi Zero 2? The methods
of turning off Firefox's multi-process mode don't seem to work
anymore. That also shows how the 64bit builds use significantly
more RAM, which will hurt the 64bit RPi Zero 2 but not the 32bit
RPi 2.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 16/07/2025 00:29, Computer Nerd Kev wrote:

druck <news@druck.org.uk> wrote:

On 10/07/2025 00:02, Computer Nerd Kev wrote:

The odd thing is that I ran Firefox on x86 with 512MB RAM a
couple of years ago and it wasn't nearly as bad.

Have a look at the size of the executable "then" (which is more likely
to be 20 to 25 years ago)

No it really was only two or maybe three years ago and Firefox
wasn't that much bigger then.

and now, and you'll see why a 512M Zero 2 doesn't stand a chance.

The Executable still fits easily in 512MB RAM, for some reason it
tries to allocate lots more RAM after starting and displaying the
browser window (which seems to work fine for a few seconds before
it stalls).

It seems the RAM usage increased when they started using multiple
processes:

https://erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/

Maybe on the single-core x86 PC it creates fewer processes and
therefore uses less RAM than the quad-core Pi Zero 2? The methods
of turning off Firefox's multi-process mode don't seem to work
anymore. That also shows how the 64bit builds use significantly
more RAM, which will hurt the 64bit RPi Zero 2 but not the 32bit
RPi 2.

There is also the issue that many modern websites are running memory
gobbling Javascript implementations
--
Religion is regarded by the common people as true, by the wise as
foolish, and by the rulers as useful.

(Seneca the Younger, 65 AD)


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 16 Jul 2025 09:29:38 +1000, Computer Nerd Kev wrote:

It seems the RAM usage increased when they started using multiple
processes ...

That idea was pioneered by Chrome/Chromium, I believe, as a way to improve both security and robustness.

Other browser developers eventually realized that, in spite of the
increased resource usage, it was the right thing to do.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Wed, 16 Jul 2025 00:37:57 +0100, The Natural Philosopher wrote:

There is also the issue that many modern websites are running memory
gobbling Javascript implementations

Blame that on Google, for pioneering the rCLV8rCY JavaScript implementation that greatly sped up its execution speed. Prior to that, JavaScript was
only good for adding limited interactivity to web pages. But suddenly, it became feasible to add enough code to approach the full complexity of a locally-running app -- and all entirely in the browser.

That massive leap in performance also led to JavaScript becoming usable
for back-end development, with nothing to do with browsers at all. Hence
the inception of NodeJS.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Computer Nerd Kev <not@telling.you.invalid> wrote:

druck <news@druck.org.uk> wrote:

and now, and you'll see why a 512M Zero 2 doesn't stand a chance.

The Executable still fits easily in 512MB RAM, for some reason it
tries to allocate lots more RAM after starting and displaying the
browser window (which seems to work fine for a few seconds before
it stalls).

Upgraded from Firefox 140 to 141 on the Pi Zero 2 and it's working
much better. Loads old-fashioned sites fine (though very slowly)
and some modern ones if their Javascript is blocked. With JS or
just big webpages it often gets stuck though.

Weirdly the User-Agent header it sends out says x86_64 though it
says AARCH64 within the browser. Seems it's unwise to be honest
about using ARM when talking to some web servers:

https://www.tomshardware.com/software/youtube-uses-lower-quality-options-on-browsers-with-aarch64-arm-based-systems-reporting-x86_64-appears-to-be-a-widespread-browser-fix
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 23 Jul 2025 23:13:33 +1000, Computer Nerd Kev wrote:

Weirdly the User-Agent header it sends out says x86_64 though it says
AARCH64 within the browser. Seems it's unwise to be honest about using
ARM when talking to some web servers ...

If you want to determine the capabilities of the client system, checking
the user-agent seems a pretty na|>ve, not to say dumb, way of doing it.

It would be better to do a more directly functional check.
--- Synchronet 3.21a-Linux NewsLink 1.2