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 “V8” 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