Re: Gradual Growth of Memory Use?

Okay, I just found mention of compressed in-use memory (12 GB). You have to examine the Memory graph pane in the Task Manager.

The graph shows about 50% allocation, and 12 GB of compressed memory seems quite a high fraction. Must be stuff in the Win/11 ecosystem that has been mostly dormant while data acquisition is the only thing running for many hours. Might also be some of the Lisp ecosystem which could explain why REPL becomes laggy above 1.5 GB allocation. Right now the REPL is quite snappy at 500 MB allocation.



> On Mar 13, 2025, at 05:10, David McClain <[email protected]> wrote:
> 
> Hi Yuri,
> 
> I didn’t realize that Win/11 might be compressing memory. I don’t see how to discern this measure?
> 
> All that I see in the Performance Monitor is total allocation. Looking at the Resource Monitor I can see private, committed, working set, and shareable. No mention of any compression.
> 
> I have re-enabled my graphics plots and some telemetry. Over the past 12 hours or so, I now see this information, from local telemetry, which is showing the histogram of processing duration on each 1024 Samp block of data. Meanwhile the incoming buffers are stuffing 4096 Samps which takes about 512 ms. So my buffer ring algorithm seems to be working okay. No problems reported yet. Memory allocation is now around 500 MB, starting from 130 MB at 4 pm yesterday.
> 
> But thinking about how GC must work, I can envision that a massively long chain of CONS cells might cost quite a bit more than an array of structs. None of these data items ever get discarded and so there is really no need to go chasing pointers in them. But GC doesn’t know that. I think I should instead allocate in a static region that GC can ignore.
> 
> <PastedGraphic-1.png>
> 
> 
> 
>> On Mar 13, 2025, at 00:30, Yuri Davidovsky <[email protected]> wrote:
>> 
>> 
>> 
>>> On 13 Mar 2025, at 02:42, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>>> 
>>> LWW seems quite speedy as long as the memory image in use remains below 1.5 GB. Something happens once you cross above that allocation. Perhaps just overly long CONS chains?
>> 
>> Could that be OS RAM compression kicking in? Seems like the desktop systems are quite conservative nowadays when it comes to swapping things out, memory compression seems to be used more commonly even when there is ram to spare. Do you see a corresponding increase of compressed ram in the task manager when issues start with the lisp image?
> 


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html