I've tried kitty, alacritty, ghostty, wezterm, and konsole (all on X11), but I keep coming back to xfce4-terminal because it opens near instantly and has the least input latency of any of the other terminal emulators I've tried. It also uses very little memory in comparison (with 6 windows open and a fair bit in each scrollback buffer):
Private + Shared = RAM used Program
31.2 MiB + 10.7 MiB = 42.0 MiB xfce4-terminal
I've been on xterm since I've started using Linux seriously in 2008. I probably wouldnt have tested it because was probably a bit obscure then like it is now. It's not perfect, it's baroque, has terrible configurability, no tabs and an ugly context menu. But it's honestly the only usable terminal, none other has stuck with me. Most are far too sluggish to even start up. Then there is key input latency. Then some of the newer ones are only usable with good gpu support, but not from a VM like Virtualbox or maybe VMware where graphics isnt working great.
Another thing for a very long time has been that most other terminals don't support bitmap fonts. This was/is critical for lower DPI monitors. Today I've mostly made the switch to TTF fonts.
Thank God for this comment, for a minute I thought I was the only one!
I've been using plain xterm/uxterm with black on white since 2000 at least.
With Vim gaining :terminal support, I need nothing else - I have tabs, splits, proper scrollback buffer navigation because the scroll buffer is a vim buffer...
I generally use alacritty but used rxvt back when. That's a name I've not heard in awhile!
I tried `cat /dev/random` in alacritty, rxvt, and xterm to compare output speed.
rxvt and xterm both start 'instantly' on my laptop. With alacritty it's slower.
Scroll speed of both rxvt and xterm are very similar though xterm seems to win by a little. Both blow the doors off alacritty though.
I'm not sure if this is a fair test, and hence why I posted, but if it is this is a very easy way to get a feel for the difference.
> I expected gnome-terminal's memory usage to be in line with konsole (KDE's default terminal), but gnome-terminal shows remarkably well in this test
In tipical GNOME fashion, they have decided to replace this largely working piece of software with on with one that places solidly at the bottom of the article's list (ptyxis).
Almost all of that is Mesa shaders and GTK's CPU side font-cache for GL/Vulkan, compiled CSS state, FWIW.
If you run:
GSK_RENDERER=cairo ptyxis -s
You can verify that with 69,985 here RES and 52,428 of that SHR. With 5 tabs open it jumped to 71,208 here. Presumably for the encrypted scrollback pre-allocations.
You still may not choose to use it, but it should stay relatively similar the more tabs you open.
Also, it's not a core GNOME app. It's just an app I wrote for me that the distros seem to have liked for its design/platform integration.
Thanks for writing it! I was very skeptical initially, but after using it I'm a fan. I also appreciate that I can script settings using gsettings, so I can configure it easily on new systems without having to touch the GUI (though the GUI settings are well thought out and nice to use when you don't know what you need yet).
Wait, what? ptyxis is not the default GNOME termjnal. It is the terminal of choice for both Ubuntu and Fedora, but the default terminal in GNOME is Console, internally known as kgx: https://en.wikipedia.org/wiki/GNOME_Terminal.
ptyxis has a few features that gnome-terminal doesn't and which are really handy. Namely, being able to list containers running on the system and then being able to select one to get a terminal running inside the container. Not sure that warrants replacing gnome-terminal but it is really handy if you use containers a lot.
The good news is that before writing Ptyxis, I also ported GNOME Terminal to GTK 4 and doubled the performance of VTE. So you know, use whatever you like.
I've been using st-terminal[1] for 5-6 years at this point. It starts instantly, uses ~10mb of Ram and has almost zero latency. It's especially apparent on X11 without compositing enabled.
I tried ghostty the last year and I was instantly turned off by how much ram it hogs, but even more horrible was that it was using close to 10% cpu just sitting idly, doing absolutely nothing. It also felt at least twice as slow.
I need my terminal to display text, do scrollback and nothing else. I don't need gpu rendering, I don't need any fancy features, just be respectful to my system resources. Is it too much to ask?
Today I learned (thanks to this article) that I can use timg to display images right in my standard macOS terminal, even without switching to kitty or any other fancy thing. Not pixel perfect of course, but still, much faster to go through icons or other pictures than opening in a separate Preview window. A simple "brew install timg" worked for me. Will surely save me some clicks!
foot also offers a client/server architecture.
If you start a foot server (e.g. with a systemd service), you can use `footclient -N`.
This may reduce the memory pressure of running many terminals.
This is similar to the `kitty --singleinstance` mentioned in another comment by amarshall.
edit: the article did mention st but claimed it had no scrollback, that's what the patches are for. st-flexipatch makes it easy to enable or disable the patches via c preprocessor defines.
One of many reasons I left Debian behind for desktop things over a decade ago. I love the project and appreciate the history, but things can get pretty long in the tooth after awhile. Flatpaks help.
I wish Debian had an Arch style bleeding edge fork. Till then I've been happy using Arch, I had my last straw when a program needed a more up to date GLIBC on Debian. That's such a can of worms to resolve, I just went ahead and gave Endeavour (Arch based) a try and havent gone back or changed distros ever since.
If someone ever makes a Debian distro that is bleeding edge and supports Nvidia drivers (basically a more bleeding edge Ubuntu) I'd be all ears.
Just download the source and build the binaries you need. I use GNU stow as a parallel package manager within /usr/local that plays nice with the rest of the OS. It isn't hard for most sane programs with proper build scripting.
That's an odd reason. There's many ways to get packages these days without being dependent on your distro's repos (like using brew or Nix, or just grabbing the binaries directly). Ghostty is a very popular terminal right now, so it's a shame that the author left it out of the comparison.
My current Ghostty session on macOS is holding on to 127.8 MiB of real memory, and only 37.5 MiB of private memory. What's the Linux build up to that makes up for that difference?
I use to have a few terms active in the very early days of Linux. When I heard about screen/tmux now I just have 1 term open and multiple tmux sessions.
I think if you can get use to tmux/screen you may like that better :)
I've faced the many terminal tabs issue. In a way tmux actually makes it worse as I'm used to the running app being in the title, and tmux obscures that (now there's just "client"). But also better as I found a great session restore plugin; always drove me a bit crazy when something happened that either killed the terminal app or triggered a full restart, and my tabs were lost.
I find A good window manager to be nicer for a bunch of terminals than tmux, where tmux really shines is when you want a bunch of terminals on a remote system.
Probably want `kitty --single-instance` to reduce memory usage when opening multiple.
https://sw.kovidgoyal.net/kitty/invocation/#cmdoption-kitty-...
I've tried kitty, alacritty, ghostty, wezterm, and konsole (all on X11), but I keep coming back to xfce4-terminal because it opens near instantly and has the least input latency of any of the other terminal emulators I've tried. It also uses very little memory in comparison (with 6 windows open and a fair bit in each scrollback buffer):
I was curious to see what the actual latency was, so I used Pavel Fatin's https://pavelfatin.com/typometer/.
Notes: This system is running Arch, with kernel 7.0.3, scx_bpfland, and i3 on X11. Primary GPU is an integrated Intel GPU.
Using picom:
Using picom --realtime: No picom: Running on the NVIDIA GPU just for fun: Slightly surprised that xterm doesn't top the chart on the picom category.I've been on xterm since I've started using Linux seriously in 2008. I probably wouldnt have tested it because was probably a bit obscure then like it is now. It's not perfect, it's baroque, has terrible configurability, no tabs and an ugly context menu. But it's honestly the only usable terminal, none other has stuck with me. Most are far too sluggish to even start up. Then there is key input latency. Then some of the newer ones are only usable with good gpu support, but not from a VM like Virtualbox or maybe VMware where graphics isnt working great.
Another thing for a very long time has been that most other terminals don't support bitmap fonts. This was/is critical for lower DPI monitors. Today I've mostly made the switch to TTF fonts.
Thank God for this comment, for a minute I thought I was the only one!
I've been using plain xterm/uxterm with black on white since 2000 at least.
With Vim gaining :terminal support, I need nothing else - I have tabs, splits, proper scrollback buffer navigation because the scroll buffer is a vim buffer...
Honestly, only emacs is a better terminal.
I used to like rxvt (or its clone rxvt-unicode) when using X-Windows. What are your thoughts about it compared to xterm?
I generally use alacritty but used rxvt back when. That's a name I've not heard in awhile!
I tried `cat /dev/random` in alacritty, rxvt, and xterm to compare output speed. rxvt and xterm both start 'instantly' on my laptop. With alacritty it's slower. Scroll speed of both rxvt and xterm are very similar though xterm seems to win by a little. Both blow the doors off alacritty though.
I'm not sure if this is a fair test, and hence why I posted, but if it is this is a very easy way to get a feel for the difference.
> I expected gnome-terminal's memory usage to be in line with konsole (KDE's default terminal), but gnome-terminal shows remarkably well in this test
In tipical GNOME fashion, they have decided to replace this largely working piece of software with on with one that places solidly at the bottom of the article's list (ptyxis).
Almost all of that is Mesa shaders and GTK's CPU side font-cache for GL/Vulkan, compiled CSS state, FWIW.
If you run:
GSK_RENDERER=cairo ptyxis -s
You can verify that with 69,985 here RES and 52,428 of that SHR. With 5 tabs open it jumped to 71,208 here. Presumably for the encrypted scrollback pre-allocations.
You still may not choose to use it, but it should stay relatively similar the more tabs you open.
Also, it's not a core GNOME app. It's just an app I wrote for me that the distros seem to have liked for its design/platform integration.
Thanks for writing it! I was very skeptical initially, but after using it I'm a fan. I also appreciate that I can script settings using gsettings, so I can configure it easily on new systems without having to touch the GUI (though the GUI settings are well thought out and nice to use when you don't know what you need yet).
Wait, what? ptyxis is not the default GNOME termjnal. It is the terminal of choice for both Ubuntu and Fedora, but the default terminal in GNOME is Console, internally known as kgx: https://en.wikipedia.org/wiki/GNOME_Terminal.
I did not know about this. I used it on Fedora, and I thought Fedora was as close to "default GNOME" as possible.
Gnome Console seems to be intended for people who don't use terminals. I quickly install GNOME terminal for real use.
ptyxis has a few features that gnome-terminal doesn't and which are really handy. Namely, being able to list containers running on the system and then being able to select one to get a terminal running inside the container. Not sure that warrants replacing gnome-terminal but it is really handy if you use containers a lot.
The good news is that before writing Ptyxis, I also ported GNOME Terminal to GTK 4 and doubled the performance of VTE. So you know, use whatever you like.
Hey thanks for your work, I’m really enjoying Ptyxis on Arch.
Cool, but can you set the colors?
I've been using st-terminal[1] for 5-6 years at this point. It starts instantly, uses ~10mb of Ram and has almost zero latency. It's especially apparent on X11 without compositing enabled.
I tried ghostty the last year and I was instantly turned off by how much ram it hogs, but even more horrible was that it was using close to 10% cpu just sitting idly, doing absolutely nothing. It also felt at least twice as slow.
I need my terminal to display text, do scrollback and nothing else. I don't need gpu rendering, I don't need any fancy features, just be respectful to my system resources. Is it too much to ask?
[1] https://st.suckless.org/
Today I learned (thanks to this article) that I can use timg to display images right in my standard macOS terminal, even without switching to kitty or any other fancy thing. Not pixel perfect of course, but still, much faster to go through icons or other pictures than opening in a separate Preview window. A simple "brew install timg" worked for me. Will surely save me some clicks!
For that specific use case you could also try `yazi`[0], which is a TUI file browser that has image (and other filetypes) preview built in.
[0] https://github.com/sxyazi/yazi
foot also offers a client/server architecture. If you start a foot server (e.g. with a systemd service), you can use `footclient -N`. This may reduce the memory pressure of running many terminals.
This is similar to the `kitty --singleinstance` mentioned in another comment by amarshall.
i've been using xst https://github.com/gnotclub/xst, a fork of suckless st https://st.suckless.org/ for a long period, but there's also st-flexipatch https://github.com/bakkeby/st-flexipatch available which now includes sixel support
edit: the article did mention st but claimed it had no scrollback, that's what the patches are for. st-flexipatch makes it easy to enable or disable the patches via c preprocessor defines.
I've honestly never given terminal memory usage a second thought. Here is the memory usage of konsole version 26.04.1 on CachyOS.
Above is with two tabs open. Below is 18 tabs open. In the settings the memory limit is set to 192 MB (Default) Using ps_mem.py [1] - I suggest using this instead of ps to avoid confusion around shared memory.[1] - https://github.com/pixelb/ps_mem
there is more to your choice of terminal emulators than pure memory usage.
https://lwn.net/Articles/749992/
https://lwn.net/Articles/751763/
Why not try Ghostty? https://ghostty.org
He said it: because it isn't in Debian repos.
One of many reasons I left Debian behind for desktop things over a decade ago. I love the project and appreciate the history, but things can get pretty long in the tooth after awhile. Flatpaks help.
I wish Debian had an Arch style bleeding edge fork. Till then I've been happy using Arch, I had my last straw when a program needed a more up to date GLIBC on Debian. That's such a can of worms to resolve, I just went ahead and gave Endeavour (Arch based) a try and havent gone back or changed distros ever since.
If someone ever makes a Debian distro that is bleeding edge and supports Nvidia drivers (basically a more bleeding edge Ubuntu) I'd be all ears.
Aren't you describing either Debian Testing or Debian Unstable? (Depending on just how bleeding edge you want.)
You cannot find nvidia drivers on there. The philosophy of Debian forbids it.
Just download the source and build the binaries you need. I use GNU stow as a parallel package manager within /usr/local that plays nice with the rest of the OS. It isn't hard for most sane programs with proper build scripting.
Went to an atomic distro + flatpak.
That's an odd reason. There's many ways to get packages these days without being dependent on your distro's repos (like using brew or Nix, or just grabbing the binaries directly). Ghostty is a very popular terminal right now, so it's a shame that the author left it out of the comparison.
the (walled) garden is a very good place to be
Its horrible with memory, launching a single empty terminal uses 307MiB on my Linux system
My current Ghostty session on macOS is holding on to 127.8 MiB of real memory, and only 37.5 MiB of private memory. What's the Linux build up to that makes up for that difference?
Why is xfce4-terminal missing?
It's just using libvte like gnome-terminal and lxterminal, so I doubt it's much different from them.
Oh I see, about Terminator?
/usr/bin/xfce4-terminal 64176
I like xfce4-terminal as a compromise. Good bang for the memory buck.
I'm using wezterm in KDE Plamas in Wayland.
I use to have a few terms active in the very early days of Linux. When I heard about screen/tmux now I just have 1 term open and multiple tmux sessions.
I think if you can get use to tmux/screen you may like that better :)
I've faced the many terminal tabs issue. In a way tmux actually makes it worse as I'm used to the running app being in the title, and tmux obscures that (now there's just "client"). But also better as I found a great session restore plugin; always drove me a bit crazy when something happened that either killed the terminal app or triggered a full restart, and my tabs were lost.
I find A good window manager to be nicer for a bunch of terminals than tmux, where tmux really shines is when you want a bunch of terminals on a remote system.