> your expectations of efficiency are contrary to the basic programming
principle: that a program should use only as much memory as it actually needs
for completing the task and that memory usage should be optimized.
That is only a "basic programming principle" if RAM is scarce. RAM is not
scarce in modern computers. Since we're talking about Web browsers, let's
look at those as an example: I looked up benchmarks for Web browsers, and
Google Chrome on GNU/Linux seems to use the most RAM out of all the major
browsers at around 1.5GB. That amount is no problem if you have 4, 8, 16 GB
of RAM. And modern computers do have that much RAM, or even more than that.
It's not 1999 anymore.
> efficiency in programming is the art of optimizing resource usage, not of
Using RAM that isn't being used for anything else is not "wasting resources".
What is wasting resources is spending CPU time (which uses an actual
resource, electricity) redundantly to save RAM that you don't need to save.
> RAM's speed is not infinite and RAM access is sequential.
RAM is random-access, not "sequential". It's kind of in its name. As for
speed, yeah, of course it takes time, but not that much. Recalculating
redundantly almost always takes longer.
Here, I'll prove it:
The first one uses variables. The second one recalculates everything only
based on the original three variables, i.e. avoids unnecessary RAM use. I get
about 13.5 seconds with the one that uses RAM freely, and about 19 seconds
(much slower) with the one that recalculates everything redundantly.
> The Linux kernel can be tuned to work in direction of keeping more memory
free (swapping more aggressively) or to keep cache in RAM for longer.
Controls for swapping don't "keep more memory free". Swapping only occurs if
your RAM is past full, therefore requiring the use of the disk. Which is
always much slower than using RAM, hence why if you're swapping, you need to
cut down your RAM use.
> but that doesn't mean that programs should simply occupy lots or all
because there is plenty of it and/or because RAM is faster than HDD.
They should use all the RAM they have a use for. I never said that programs
should throw meaningless data into RAM just for laughs.
> Being random access has nothing to do with fragmentation.
But it does have to do with the consequences of fragmentation. Fragmented RAM
is not going to make a meaningful difference to access speed in real terms. A
fragmented disk is going to cause problems because you can only access one
physical location at a time.
> It is more time consuming to manage scattered memory blocks and thousand of
pointers than reading a whole block at once.
I think "thousands" is a bit of a stretch, to say the least. Most of the time
you're allocating RAM, it's such a tiny, tiny fraction of how much RAM is
Let's say you malloc for an array of 10,000 64-bit integers. That's 640,000
bits = 80,000 bytes = 80 KB. That's a tiny, tiny fraction of the multiple
gigabytes of RAM typically available, and most of the time you're not using
arrays that huge.
But how about you prove that running a program on a system using most of its
RAM (but without swapping) is slower than on a system using only half its
RAM? It would be a lot more convincing than a bunch of ifs, buts, and maybes.
> So back to what lightweight means: Usually that implies low resource usage,
not exhausting every single bit of the system (which creates a heavy weight
for the system).
That's not a clarification. It's too vague to have any meaning.