04:03 <ericonr> dnkl: I guess I will be forced to build foot from master, both compositor and foot are each using 155G of virtual memory :D

04:04 <ericonr> I'm starting to think it can't be only the URL thing

04:10 <ericonr> ok, built and updated, restarted everything

04:10 <ericonr> we'll see what happens now

06:34 <ericonr> 21.0G 391M 385M S 4.6 2.5 0:49.87 foot --server and 23.2G 483M 473M S 4.4 3.1 2:58.24 wayfire

06:34 <ericonr> https://0x0.st/-OpG.txt maps for foot and https://0x0.st/-OpD.txt maps for wayfire

06:34 <ericonr> imma ask in #wayfire about this

06:41 <ericonr> virtual usage from both foot and wayfire seems to increase by ~500M when a new footclient pops up, and decreases by 500M again once it quits

06:41 <ericonr> the usage seems to increase mainly while I'm not looking, if that makes sense?

06:43 <ericonr> would it make sense that usage increases because foot is adding a bunch of htop and bmon output to a scrollback buffer? so having the tmux windows with those programs open and unfocused makes foot memory usage increase by a bunch

06:44 <ericonr> yes!

06:44 <ericonr> killing the footclient displaying tmux (with htop and bmon) decreased virtual memory usage by 30G

07:55 <dnkl> ericonr: 30G virtual memory sounds like a lot for a single footclient. Scrollback memory is allocated in demand and uses "real" memory

07:55 <dnkl> on*

07:56 <dnkl> ericonr: the +-500MB makes sense though, and is expected.

07:58 <dnkl> https://codeberg.org/dnkl/foot/src/branch/master/doc/foot.ini.5.scd#L1024-L1066

14:27 <lanodan> Virtual memory usually just doesn't really matters anyway, RES and SHM are the columns you should be looking at.

14:33 <ericonr> that one also increases dramatically in %