Comment 6 for bug 1430620

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

> But I run out of ram space very rarely.

Maybe because you don't allow large (let alone infinite) scrollback.

> It's highly elegant to keep volatile data in RAM unless RAM is full.

How do you think gnome-terminal should handle that? Suppose you have 4 GB of ram, shall it consume up to 3 GB and then starting using the disk? Sounds not only hard to implement, but also why should it take away RAM from other apps?

That being said, I was not the one coming up with this design, see the mentioned links for people who have more experience than me on topics like memory fragmentation and OOM killer. I just pointed you to their choice, which I also happen to agree with.

> My particular desktop SSD is at 19% lifetime

After using it for how long, which apps, etc.? How much do you think gnome-terminal contributed to this? As I said, I'm happy to let you know that vte 0.40 will save a lot by compressing the contents.

My DSLR is at 25% of its lifetime. 25k pictures, 100k promised by the manufacturer. And it was definitely more expensive than a large SSD :)

> Aside from that writing to disk is dramatically more system overhead, compared to RAM.

In case of g-t/vte, the goal was not to reduce this overhead as much as possible, but to come up with a design that allows you to have freaking huge (practically infinite) scrollback buffers. Even with writing to disk, vte performs reasonably well among terminal emulators when cat'ing a large file, and disk writing speed is not the bottleneck, not even with HDD. And cat'ing a large file is really not the typical use case.

If you really feel like hacking: download latest vte (0.39.x or git), and modify src/vtestream-file.h _file_write() so that a static variable (that is a variable shared across all vte instances) is incremented by len every time, and printed to some file every now and then. Compile and install, overwriting Ubuntu's version of the lib. After restarting gnome-terminal, this will tell you how much data your g-t writes during a day. I'd be interested in seeing that number!

Also see the upstream links with discussions about putting these temporary files under some tmpfs, its pros and cons.