The Ghostty memory usage memes are dead with the upcoming 1.4 release, much to the dismay of internet trolls everywhere. ~10x less memory for a visible window. ~450x lower for a non-visible window. Very reasonable compared to other terminals with 10 tabs. This was the result of a lot of incremental hard work, but there were two big wins. One I talked about before which was scrollback compression. I want to note that these charts do NOT include scrollback, so with scrollback the results are more dramatic! The other big win is that we free almost all GPU resources when a window is fully occluded (covered by another window, minimized, etc.). We triple-buffer our screens so for large screens this has major savings. Those account for a large chunk of the improvements, but we also had dozens of incremental 1% wins here, a few KB there, etc. throughout the 1.4 cycle. And there are more coming! I noted before that Ghostty's memory waste was all in the app layer and we can see it here. libghostty has always been very tight in comparison and I've shown comparisons to other embedded terminal libraries elsewhere. And importantly, the charts below use the same grid sizes with a very small +/-2% difference due to differences in how cell metrics are calculated between terminals.

Btw this is why computer science matters. Yes, you can self teach it if you really want to (I personally wouldn't have had the discipline, so college was a way better force). However you learn it, the theoretical fundamentals matter and get applied to work every single day.

I'm willing to engage with anyone. And the algorithm lifts this so others can too. I try to combat engagement bait with an attempt towards rational discourse as much as I can, because I don't want people to think that professional people actually work like memes do. When others don't respond in kind, it naturally reveals their true clown nature. That wasn't the case this time, again speaking in generalities.

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 default scrollback limit from 10MB to 50MB, because on average a full scrollback will still compress smaller than the prior limit. More history, for free. ("Unlimited", disk-paged history is on the roadmap too) Let's talk about cool implementation details, cause this was fun. First, the data structure and memory layout ("PageList") I wrote two years ago finally pays off! One of its traits is that screen memory is backed by a linked list of page-aligned, page-sized (or page-multiple-sized) blocks. Because each block is page-aligned and page-sized, we can use madvise to discard its physical backing while keeping the virtual address space reserved. Compressed pages therefore disappear from resident memory, but decompression is still guaranteed because the address space remains valid and we simply fault new pages back in as needed. We use the same trick for our memory pools, too. Unallocated pool pages don't count as resident memory, saving another couple of MB per terminal. This functionality is also available to libghostty-vt consumers via new `ghostty_terminal_compress` APIs. The consumer decides when the appropriate time to compress is and the APIs advise on compressability.

Ghostty is now indisputably the fastest terminal emulator at IO throughput, by a very large margin. On ASCII, Unicode, and CSI tests, Ghostty is more than 2x (double!) faster than any other leading "fast" terminal. These changes are directly in libghostty, too, so everyone wins. `time cat 150MB_ascii.txt`: - Ghostty nightly: 575ms - Ghostty 1.3.2: 1.5sec - Alacritty: 1.2sec - Kitty: 1.7sec - Warp: 3.8sec - iTerm2, Terminal: stopped after 60s `time cat 150MB_unicode.txt` (mixed languages): - Ghostty nightly: 536ms - Ghostty 1.3.2: 1.22sec - Alacritty: 1.05s - Kitty: 1.35s - Warp: 3.4s - iTerm2, Terminal: stopped after 60s `DOOM-Fire-Zig` (an IO test): - Ghostty nightly: 842fps - Ghostty 1.3.2: 532fps - Kitty: 485fps - Alacritty: 593fps - Warp: 577fps - iTerm2, Terminal: 60fps (yes, 60) To quickly address the "cat speed doesn't matter" naysayers: this is a direct test of how many bytes/second you can push through a terminal. It doesn't cover just "read big file" but also "how much can a TUI do". The tests above test various shapes of inputs (plain ascii, unicode/wide chars, csi-heavy loads, etc.). IO throughput is incredibly important. Most of these improvements apply to libghostty-vt consumers too, so any libghostty-based terminals will instantly see huge throughput improvements by simply upgrading (ABI compatible). I'll cover the exact improvements in a blog post in the future. These results are the result of 6 separate optimizations.

This is why PR diff speed matters. This isn't a dunk on GitHub specifically, because GitLab, Forgejo, etc. are all equal or worse. But this is the kind of thing that drives me nuts, because this is a core workflow and its slow enough I literally take my hands off the keyboard. Btw, when my mouse jiggles on the left, its because the page is literally skipping frames and I'm instinctively shaking my mouse to see if it'll respond. And on the keyboard input you can literally here me finish typing before a letter even shows up. For someone like me who is an expert at these tools, my brain navigates the tool dramatically faster than it can keep up, and that is not good. The tool should not get in the way.