Hi,
+1 for Noel from my POV here. Modern machines/OSes do more what MACH4 kernel did 1st - in one sentence, they use ssd/hd as mem, ram as swap space for that to temporarily *swap in* space from disk. That means that writing yourself writes also just to mem with the *same* speed/attributes, but has to potentially somehow reformat that data - at moving in and out.
Only cases to do handish maybe 32bit (which is dead - or should be) or mobiles (which use similar tec & have also more res than needed).
I thought myself often and intense about that (even with binary quadratic, pre-scaled copies to only swap in needed size of pixel, etc...) but abandoned due to more and more not being worth it.
Just my 2ct.
On Mon, 3 Apr 2023 at 14:04, Tomaž Vajngerl <tomaz.vajngerl@xxxxxxxxxxxxxxx> wrote:
One of the issues with letting the OS deal with all that is that the OS has no idea what and when it can swap out - it just uses LRU when there is a memory pressure, or not. We can do it much more effectively and do less work, for example not keep it in the
I think we're going to have to agree to disagree here.
I think our current code is doing the best that it can, but it fundamentally cannot make as good a decision as the OS because it does not have the same global view of the machine.
For example, in performance profiles, I regularly see my very powerful Windows machine with tons of RAM running like a Pentium because LibreOffice is spending all its time unnecessarily pushing things into temp files [0].
Presumably, people who work primarily on Linux never see these issues because /tmp on Linux acts like a RAM drive on fast machines with lots of memory.
So I would personally prefer that we just let the LRU algorithm of the OS swap logic do its thing.
Regards, Noel.
[0] This was the primary motivation behind the utl::TempFileFast work, which helped some cases, but in other places, Libreoffice still insists on having a named temporary file (mostly because of the UCB layer).
-- -- ALG (PGP: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)
