<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>+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.</p>
<p>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).</p>
<p>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.</p>
<p>Just my 2ct.<br>
</p>
<div class="moz-cite-prefix">On 4/4/23 14:07, Noel Grandin wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFYHVnVEMvwP0TAyhyVgTs3sj=HmP59CPyRQeO3KazmMtbVkJA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 3 Apr 2023 at 14:04,
Tomaž Vajngerl <<a
href="mailto:tomaz.vajngerl@collabora.co.uk"
moz-do-not-send="true" class="moz-txt-link-freetext">tomaz.vajngerl@collabora.co.uk</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>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
</p>
</div>
</blockquote>
<div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">I think we're going
to have to agree to disagree here. </div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">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.</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">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].</div>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">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.</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">So I would personally
prefer that we just let the LRU algorithm of the OS swap
logic do its thing.</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">Regards, Noel.</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif">[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).</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif"><br>
</div>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
--
ALG (PGP: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)</pre>
</body>
</html>