Very high RAM usage

[niko256]

Hey! I've been using tdf recently and noticed some issues with memory usage that are actually quite critical.

I started investigating this because my system completely froze and became unresponsive a few times, forcing a hard reboot. This happened specifically after using 'zoom in' mode (i assume this triggered a heavy re-render that filled up my RAM). I couldn't find any existing issues about this, so i initially thought it was problem with my setup. I checked and got similar results on another machine as well. (Arch + Ghostty in both cases).

However, i ran some tests with the same ~1000 page textbook and found that the memory usage is extremely high.

Here are the measurements (tracking RSS every sec ) :

watch -n 1 'ps -C tdf -o rss= | awk "{s+=\$1} END{print s/1024 \" MB\"}"'

1) Default run (immediately after opening) :

    Every 1.0s: ps -C tdf -o r… archlinux: 05:55:28 PM
    in 0.007s (0)

8897.39 MB

Tbh, 8.9GB looks very unsafe and unpredictable for the user.

2) Run with -p 2 flag : memory starts low, but after scrolling through about 200pages:

Every 1.0s: ps -C tdf -o r… archlinux: 05:56:54 PM
in 0.007s (0)
1153.61 MB

1.15 GB still feels like way too much for just viewing a portion of a document.

I took a look at the sources what is going on.

I understand that the issue in the first case is that tdf renders the entire document at once. But my first question is: why is --prerender behavior set to All by default? I've been thinking about it, but i couldn't come up with a scenario where this is necessary as a default. Maybe i didn't get something. Why not set the default rendering window to 20-30 pages?

More generally, I noticed that tdf keeps rendered pages in a Vec for the whole runtime. It seems like when people read, they operate within a certain "context window", so there is no need to keep all rendered pages in memory for the entire runtime of the app.

Maybe we could solve this linear memory growth if we introduced a page eviction policy at the display level, using like a sliding window or LRU cache approach. This way, we could drop old pages from held memory and re-render them on demand.

Please let me know if this sounds reasonable or if I'm missing some context. If you are open to this, I can work on a PR.

Anyway, thanks a lot for tdf! I've been looking for something like this for a long time.

[advait87]

What's interesting is that I tried to reproduce it. And the memory usage goes insanely high only when the Kitty Terminal's window size is big, for small sizes, it doesn't go Mega Kaboom. But even then it's much much higher for a pdf viewer that I'd consider minimal.

[itsjunetime]

Yeah, tdf is extremely memory-hungry. My machine has enough memory and I personally like the full-prerender so that when I'm searching through a whole document, navigating to each next result is very quick. I definitely understand the argument for limiting it.

I think there's a few things that we should/could do here:

1. Maybe the default prerender limit could be dependent upon available memory? E.g. by default, we only take up 1/4 of available memory while prerendering (unless you specify a different amount, ofc)
2. I think some sort of LRU cache or window is a great idea. Absolutely no opposition to that - if you'd be interested in contributing something like that, I would love to have that. We could also keep some sort of accounting on how much memory the rendered pages are taking up in memory, and allow the user to just configure how much memory they're ok with tdf taking up overall? Any of these options is chill with me.
3. I think it could also be very useful to trap whatever signal the system sends when it's running low on memory (that's a thing, right? I'm not misremembering?), and evict pages based on that.

If you're interested in working on any of these things, let me know. I'll probably split them into separate issues so that they're easier to track, unless someone objects.

[itsjunetime]

Another thought: On kitty, we have the option to send over the image as a png instead of as raw data. At the moment, we just write the whole image into a vec that contains each individual pixel (since it's quicker than changing formats), but maybe (on kitty only) we could spin off a background thread to like convert all in-memory images to pngs and compress them with oxipng or smth like that, so that memory usage could actually go down while you're not moving around? Maybe that's too much work but it could be nice

[niko256]

Thanks for the ideas! I'm in.
I think starting with basic lru eviction makes sense. We could add two options for cache limit (by page count and by mem size). I expect this alone should already help a lot with the issue. I'll start implementing this and open a PR when it's ready and will bring some intermediate results along the way.

Btw i like the idea about handling memory pressure signals and i'll look into how to do that cross-platform

[advait87]

Hi people, so I'm a rust newbie, but I've already started learning. I went through this project for past 2 days, basically did logging to figure out where was the problem.

If it's not urgent, I can work on this and submit a PR within a week. I cannot confirm cross platform use, but I'll test on mac and linux. But I totally understand if you want to do it properly yourselves. That said, I LOVE this project, and will be contributing to it, the zoom feature isn't implemented properly, I also want to look into that, and ig that may be it regarding features, (off the top of my head), when other feature requests do come, I'll be very much excited to contribute.

Thanks.