Video wird geladen...
Video konnte nicht geladen werden
Ghostty is getting automatic scrollback compression, resulting in 70 to 90% less physical memory usage. It happens incrementally when idle, so it had no measurable effect on IO throughput. I'm not aware of any other mainstream terminal that does this. Demo video below! The gains let us increase the... show more
167,505 Aufrufe • vor 3 Monaten •via X (Twitter)
44 Kommentare

vte / gnome-terminal have been doing gzip compression on the scrollback for decades. :)

Good to know! Thank you.

Assuming that the content of the history is more or less consistent, do you think you could get even more compression “for free” by training a zstd dictionary on the first N lines of history and then using that dictionary for the next N*M lines? (Tuning N and M up to you)

Yes absolutely. I actually tried this and got up to 95% compression. But libghostty-vt has a no C dependency policy, so we're going with something we can hand-maintain first.

inb4 I pilot an LLM-driven port of zstd to Zig 😆… I’ve already wrapped it for my zig stuff, but obviously that’s still C. I’d do it fully if I had the time

Kudos, I love that you are you are being careful not wasting memory while managing data that's already relatively small. (vs practically any Electron apps using 900 MB after I opened it for 30 seconds to send two messages).

i absolutely love how you find all these tiny things and then go down an insane rabbit hole

PageList also made my lossless binary snapshots much easier for syncing state between clients. Excited to see how portable this work is for the WASM version so that my remote clients can get some memory savings as well

Yep, thats part of the design is that we can encode the memory directly and transfer and its accurate. We aren't leveraging that, sounds like you are :) but we will!

Nice, ya it was extremely helpful for my multiplexer + remote clients. Thinking out loud, I wonder if your secret multiplexer is what will push state transfer into libghostty 👀

This is an excellent technical post. Is there a draft chnageset we can view of the new scroll back compression? Thanks for doing this.

Neat hack!

you’re spoiling us 🥹

The part I'd want to see benchmarked is fault latency on the first scroll after a long idle period, since you're going from zero resident pages to decompressing potentially tens of MB synchronously. Did that end up being imperceptible or did you have to tune the compression algorithm for fast decompress over ratio?

Yeah I benchmarked this heavily and had to tune the compression as you said. Our decompression speeds are something like 10 GB/s and a page is roughly 400 KB so it decompresses more than fast enough so we don’t even skip a frame. (Note all the compressed pages are in memory still too so disk isn’t a problem yet)

10 GB/s on 400KB pages - that's tight. Keeping decompression that fast while compressing well is the real tuning challenge.

Lol I did not know I could be excited about a TUI. Nonetheless, here we are.

This is awesome, thank you!

blinking cursor... Now I know @mitchellh is probably really not caring the battery life.

Oooooh I’m actually working on something around this. :) (Moving to a CPU timer plus CPU rendering while on battery for the cursor blink). Should be basically idle. We already drop our framerate down on idle battery though

Wonderful!

Mitch, so cool to see you follow through with ghostty. I remember when it all just started and i thought well ok another terminal! But man… Keep it up!

This is one of those magical things that sounds *so* obvious in hindsight. Would have made my life easier ten years ago if tmux supported this. :)

I think I learn more from you than any other account on X. Thanks

Thanks for sharing, @mitchellh! I’m a bit confused about how it can be possible that decompression is still guaranteed 🤔 does that imply nothing else can use the released memory (in which case, it’s not really released, is it?)

@archeologistdev How does this do under heavy memory pressure? I ask because my poor laptop is under heavy memory pressure by default

@archeologistdev For desktop OS's its fine, you end up swapping, which you would've been doing anyways, but the swap is more delayed since we're compressing along the way and you're not looking at most of it.

👏

OMG this is amazing, does any of console even attempt to do this?

Cool

This is pretty cool is there any blog or something about more details and references to source commits

Very cool! I’ll attempt to use this in our wasm version (embedded in our Tauri based app) when it lands.

Love these posts. Your previous one on tiling made me want to write tiling logic by hand for fun (vanilla css in solidjs). Thanks for the interesting write up!

would it disable itself when on battery saving mode active on the laptop?

Everytime I see optimizations like this I give a like. Maybe time to try ghostty again!

LZ4 ?

Awesome. By the way, would you consider a future version of this that uses the concept of 'purgable memory' of MacOS (& SerenityOS)? It would enable keeping the uncompressed pages alive unless the kernel actually needs them, potentially avoiding unnecessary decompression ops.

🐐

I really wanted to try ghostty, but why does it take 300megs of RAM (similar to warp) when it’s miles lighter than it?

nice

Very smart. Scroll back is rarely checked, the CPU cost (which seem to be negligible) is worth the memory saved!! 👏

Nice! MacOS is incredibly efficient at memory compression, so I wonder if some users might have gotten similar "for free" already. Is there any way to preserve the scroll history across a terminal reset? Codex seems to reset the terminal on a sigwinch, wiping the earlier text.

streaming container logs easily eats a gig of terminal memory

Amazing, great work!
