squidowl / halloy

IRC application written in Rust
GNU General Public License v3.0
1.65k stars 59 forks source link

ram usage (...?) #135

Closed ineeee closed 3 months ago

ineeee commented 1 year ago

i just noticed that halloy's ram usage is insane. i was killing another random process and noticed halloy is using 459 mb of ram. is that normal? i don't remember it happening on 2023.1-alpha1.

attached is a screenshot of task manager: image

i thought this was related to my bouncer's buffer sizes, so i left some channels and sent /msg *status ClearAllBuffers then restarted the client, however the ram usage stays around the same even with 6 empty channels.

i run windows 10, halloy 2023.2 and i'm connected to rizon via znc.

Daeraxa commented 1 year ago

On Linux I've had it open for a while but I'm only on 85.4MB built from the latest commit.

ineeee commented 1 year ago

after deleting the history folder ($config/halloy/history/) and restarting, ram usage went down by half.

image

tarkah commented 1 year ago

after deleting the history folder ($config/halloy/history/) and restarting, ram usage went down by half.

image

We keep up to the last 10,000 messages per buffer. This is probably way too high or we can make it configurable.

We only keep the full history in memory for opened buffers so closed buffers should never impact memory usage.

As for the rest of the memory usage, a lot of it comes from the wgpu renderer backend that's used. So this might partly be a directx / driver issue on windows. You can test out the software renderer by using env var ICED_BACKEND=tiny-skia to confirm that it goes way down.

ineeee commented 1 year ago

changing to the software renderer increased memory usage to ~300mb, but the font rendering looks awful (no antialising?) so i'll stick with the other one.

it would be nice to be able to change the buffer size, since i treat irc like an ephemeral messaging platform-ish so i don't care about past history.

either way i can waste a bit of ram 😅

tarkah commented 1 year ago

changing to the software renderer increased memory usage to ~300mb, but the font rendering looks awful (no antialising?) so i'll stick with the other one.

Interesting! I've mostly tested on Linux so that's where I've seen the big difference in usage between software renderer and Vulkan (wgpu uses Vulkan on linux), with Vulkan using much more memory.

it would be nice to be able to change the buffer size, since i treat irc like an ephemeral messaging platform-ish so i don't care about past history.

Agreed, we can make this configurable 👍

tarkah commented 1 year ago

I've confirmed the underlying issue to RAM usage. See the below heaptrack of app memory consumption.

The bottom two stacks are all related to text caching (span & layout caching) that Iced's (our GUI framework) text backend is doing. The 3rd stack from the bottom (3rd largest) is from the font file we load into memory. When you remove these, our actual memory usage is closer to ~30MB. This was after I opened multiple buffers with 10k messages each. Message history uses at most 3-6 MB of RAM even with multiple buffers of 10k messages open.

So this is basically down to how Iced is doing text caching. All iced applications then are currently impacted by this same issue (on both gpu accelerated and software renderer backends). I'd imagine other frameworks might benefit from using system level APIs for text so they don't incur this memory penalty but I am not sure.

As text handling isn't quite mature within the Rust ecosystem and definitely not iced, I expect this will improve in the future. I'll look to see if there's ways to optimize the caching that haven't already been explored.

image

ineeee commented 3 months ago

hi, posting more info since it was closed.

image

now uses ~144mb of ram on 13 buffers (each with 200+ lines each). seems like a huge improvement to me 👍 halloy 2024.8 on windows 10.