BinaryDataContainer swapping ? ...

[Armin Le Grand]

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 4/4/23 14:07, Noel Grandin wrote:
>
> On Mon, 3 Apr 2023 at 14:04, Tomaž Vajngerl 
> <tomaz.vajngerl at collabora.co.uk> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20230405/41af2d00/attachment.htm>