Mayayana wrote:
"Ken Blake" wrote

In general, how many applications you have open hardly matters. Much
more important is what applications they are, and especially whether
they are doing something at the moment.

Not necessarily. Pale Moon is using 150 MB RAM here just to
sit there. Firefox is similar. And they're the older versions that
don't run each instance in a separate process. If you have
40 tabs open, doing nothing, in recent vintage Firefox, you'll
still have each one loading independent instances of at least
some parts of the program.

On the other hand, visual Studio 6 (VB) loaded with a
large project loaded is using 1/8th as much RAM. Even
with the additional load of the entire MSDN help system it's
using about 1/5 of what FF takes to sit there. And I
still have more than 2/3 of my 3+ GB free.

I suspect many of the people who complain about RAM
are running bloated browsers with loads of tabs open,
in which they're logged into various sites like Google
or Facebook, and allowing videos to load in pages they're
not even looking at. Most people also don't block auto-refresh.
So things like news sites are reloading the whole thing
every few minutes.
Tabs have arguably been a disaster in that sense, making
it easy for people to keep a multitude of webpages open at
once, for no reason, at a time when webpages have become
amazingly bloated. A few years ago 100 KB was too big to load.
Now a single page that loads 20 MB is not unusual. That's
bigger than most software programs.

For Firefox, check out the size of XUL.dll. At
least on the pre 52-ESR ones, that was a "player".
It's one of the larger DLLs you'll run into.

When you build Firefox, during the linking stage,
XUL.dll takes a bit more than 3GB of RAM to link.
One time I tried it, I had to change the kernel:userspace
split, for the build to finish. A later attempt to build
32-bit Firefox, needed Visual Studio in a 64-bit OS, so
there would be sufficient RAM to finish the linking step.
I didn't keep notes, but it's possible it zoomed up
to 10GB during linking.

(If you build Chrome, there's certain value in having
32GB of RAM for your build machine.)

But once XUL.dll is loaded at runtime, if you fork multiple processes,
wouldn't they used shared code segments ? All the processes
should be able to read the code, out of a common segment.
Because code segments are not allowed to "self modify" when
running. The mapper would be set to read-only, once the
segment is loaded (attempting to write it would give some
sort of access error).

I'm sure the RAM they are wasting, is being put to good
usage storing cat photos. It can't possibly be bloated code :-)

Paul