memory eating #170

New Issue

whoami · 2022-04-11T02:59:55+03:00

whoami commented

2022-04-11 02:59:55 +03:00

❯ ps_mem -Sp $(pidof -S, aerc meli thunderbird)
 Private  +   Shared  =  RAM used   Swap used	Program

 24.3 MiB +  25.5 MiB =  49.7 MiB     0.0 KiB	aerc
314.5 MiB + 482.5 MiB = 797.0 MiB     0.0 KiB	thunderbird (2)
669.0 MiB + 672.5 MiB =   1.3 GiB     0.0 KiB	meli
---------------------------------------------
                          2.1 GiB     0.0 KiB
=============================================

``` ❯ ps_mem -Sp $(pidof -S, aerc meli thunderbird) Private + Shared = RAM used Swap used Program 24.3 MiB + 25.5 MiB = 49.7 MiB 0.0 KiB aerc 314.5 MiB + 482.5 MiB = 797.0 MiB 0.0 KiB thunderbird (2) 669.0 MiB + 672.5 MiB = 1.3 GiB 0.0 KiB meli --------------------------------------------- 2.1 GiB 0.0 KiB ============================================= ``` ![image](/attachments/aa49abb6-37ff-46ef-b1b2-28c04a0f5024)

image.png

32 KiB

Manos Pitsidianakis commented

2022-04-11 09:49:05 +03:00

That is intentional, after the 'RAM not used is RAM wasted' philosophy. Every mailbox loaded is kept in memory. But there should be a way to configure this, maybe make it opt-in so there are no surprises there. Let's add a config flag to tune the memory behavior?

Manos Pitsidianakis added the

bug

enhancement

help wanted

labels 2022-04-11 09:49:27 +03:00

whoami commented

2022-04-11 22:01:48 +03:00

Poster

I don't think that's what people expect from a program in Rust

whoami commented

2022-04-11 22:08:18 +03:00

Poster

I expected it to take up less memory than aerc. I would prefer to use Thunderbird since it consumes almost half as much memory.

I expected it to take up less memory than `aerc`. I would prefer to use `Thunderbird` since it consumes almost half as much memory.

Manos Pitsidianakis commented

2022-04-11 23:20:51 +03:00

Yeah I don't disagree with you, I explained what was the motivation (I have 32GB RAM) but RAM abundance is not something you can count on for every user. It has to be fixed to be opt-in instead.

Manos Pitsidianakis commented

2022-04-25 22:34:10 +03:00

After some investigation, we can separate the logic of fetching a Mailbox and just updating its unread/total counts in order to prevent loading it in memory needlessly.

Manos Pitsidianakis commented

2022-05-05 17:01:16 +03:00

Ughm, turns out that wasn't the culprit. Caching the terminal mailbox list in memory was what is taking most of RAM. I was able to get a release build running with just 83 MB RAM usage after removing the cached views and just redrawing the terminal on every page draw.

oblitum commented

2022-05-24 16:56:50 +03:00

Hey @epilys, did you push this massive RAM improvement? I don't see a commit reference, hence the question.

Manos Pitsidianakis commented

2022-06-04 15:59:31 +03:00

No not yet. Busy with work. I'll update this thread when I do!

Manos Pitsidianakis commented

2022-06-04 17:48:21 +03:00

I pushed a change for the conversations view here 8563bccd1b

It is in master. But I haven't changed the other views (compact, threaded) because they are column based and the code logic is different. The difference in RAM for me is big though.

I pushed a change for the conversations view here 8563bccd1b6d48dc06dd521f77228c3cbecf7613 It is in master. But I haven't changed the other views (compact, threaded) because they are column based and the code logic is different. The difference in RAM for me is big though.

oblitum commented

2022-08-16 06:00:04 +03:00

I'm using conversations on a machine, but I didn't notice that much difference in RAM usage in my case. Conversations doesn't seem very stable too, because sometimes when I select an e-mail with Enter, the content flashes open and close on the side, then to actually bring it up I press p, and it's shown. It seems to often happen with html only emails that go through w3m, but I'm not sure.

Manos Pitsidianakis commented

2022-08-16 11:55:44 +03:00

I've noticed this as well but left it half-done because of day job. The area redraws are not done correctly when an email is open. Is it easy to get some RAM usage numbers before and after this commit? Essentially it removed a big Vec<Cell> that for thousands of emails got huge.

I've noticed this as well but left it half-done because of day job. The area redraws are not done correctly when an email is open. Is it easy to get some RAM usage numbers before and after this commit? Essentially it removed a big `Vec<Cell>` that for thousands of emails got huge.

oblitum commented

2022-09-04 22:29:16 +03:00

Is it easy to get some RAM usage numbers before and after this commit? Essentially it removed a big Vec<Cell> that for thousands of emails got huge.

Something happened in latest changes that had an effect, I now do see a drastic drop in RAM numbers (from ~600MB to <100MB). So I guess no need for worries on that.

> Is it easy to get some RAM usage numbers before and after this commit? Essentially it removed a big `Vec<Cell>` that for thousands of emails got huge. Something happened in latest changes that had an effect, I now do see a drastic drop in RAM numbers (from ~600MB to <100MB). So I guess no need for worries on that.

Manos Pitsidianakis commented

2022-09-05 11:01:10 +03:00

Awesome, now I have to remove all those Vec<Cell> from everywhere, it was a premature optimization that actually called RAM problems.

Awesome, now I have to remove all those `Vec<Cell>` from everywhere, it was a premature optimization that actually called RAM problems.

Manos Pitsidianakis referenced a pull request that will close this issue

2022-09-11 17:15:49 +03:00

WIP: Don't cache CellBuffers in listing views, it takes too much RAM unnecessarily. #184

Manos Pitsidianakis closed this issue

2022-11-30 12:35:56 +02:00

Sign in to join this conversation.