[michaelmrose]

Intelligently swapping stuff from storage to RAM is literally how most OS on earth have worked for a while because as long as you have enough to keep what is liable to be used soon in RAM performance can trivially be excellent.

Libreoffice on my system spends 99.9% of the time consuming only 650MB of storage. Opening an office doc makes it require about 165MB of RAM. The consequence of it being swapped out at some point is that it takes slightly longer to get started the next time on the order of an additional 0.6 seconds.

If you watched me and the computer whilst I completed a 15 minute task with office you would note that the computer spent most of its time waiting on me rather than the other way around.

It would start 0.6 seconds faster but it wouldn't get done meaningfully faster. It would be 6 100ths of 1% faster rather than being "two orders of magnitude faster"

Worse if I really want faster libreoffice I can just start that at boot and thereafter create new writer windows in ms I wouldn't be obliged to run my entire OS from RAM to achieve this goal.

Virtually nobody runs standard desktop linux on smartphones or tablets. Distro's that target desktops and laptops should not reduce their fitness wherein they are actually used in order to be better suited for environments in which they are not.

[RetroTechie]

> Libreoffice on my system spends 99.9% of the time consuming only 650MB of storage. Opening an office doc makes it require about 165MB of RAM.

Most office type docs I have, are a few hundred KB (some smaller) to a couple of MBs.

So in your example, that means checking a small document takes (on average) in the order of 100..1000x the document's size worth of RAM. And 'only' 4x that amount of storage for the app doing it.

It wasn't long ago that file sizes vs. code to process it, were more like in the 10:1..1:10 range. 200KB text editor, 50KB text. 100KB image, image viewer under 1MB, etc.

As file sizes grow (higher screen resolutions etc), a reasonable expectation would be for code size (=file format complexity + interfacing with the OS) to lag behind. But the reverse seems to be happening. And let's not get started about browsers, or (worse) "web frameworks".

So if anything, your example nicely demonstrates the point of the article.

[michaelmrose]

There is expected to be no inherent stable ratio of RAM consumed to document size because the smallest possible document still requires 100% of the basic app and assets to be loaded in order for the app to work and thereafter this isn't expected to grow linearly with the size of the file.

What you are seeing is the expansion of the baseline app not the expansion of RAM required per kb of data. Indeed multiplying your post to a 3000 page monstrosity through the magical of cut and paste and select all only took around twice as much memory as a blank document.

> As file sizes grow (higher screen resolutions etc), a reasonable expectation would be for code size (=file format complexity + interfacing with the OS) to lag behind.

It is pretty clear that the opposite is always going to be true. Programs that don't die outright accumulate features and file formats over time multiply. Further even if the app were the same there are going to be opportunities to trade RAM consumed for a better experience that are going to make more sense the more plentiful RAM is.

There is no expectation whatsoever that coders targeting machines with 16GB of RAM and TB of storage to produce applications that are as parsimonious as those produced to target machines that have 512MB of RAM and GB of storage.

If you want parsimony you can always run emacs and export to pdf its rather fun.