Life is too short for a slow terminal
mijndertstuij.nl
mijndertstuij.nl
I can't recommend switching to mise highly enough: https://mise.en.dev/
Thank you for the recommendation, I might then also be able to ditch sdkman as well.
I can strongly recommend lazy loading in zsh in general, I use it for pyenv too (which is also slow to load, but I write Python maybe every other week or so only).
The way to do this is to use the autoload functionality in zsh and have the autoloaded script replace itself with the real shell init code for the tool in question.
With mise you get the behaviour of automatically switching when you change directories effectively for free.
1. https://github.com/nvm-sh/nvm#zsh
Edit: unless you aliased it to `node` or `npm`, which would be fine I guess but super annoying if you ran node or npm commands often. It is not worth the hassle, no one should use nvm in 2026 imo
I’m an SRE and the answer is “constantly”. I get pulled in a lot of directions, it’s way easier to maintain context if I open a new terminal or tab for each thing.
Joe asks about something, I open a terminal. Teammate asks about something, new terminal. Joe replies, I swap back to his terminal to look at the scrollback buffer.
I’m closer to you when doing more dev work. One tab running a watcher for builds and restarting the app, one tab to run tests or whatever, a couple for poking around if I need to grep or curl or whatever.
Unrelated to Mise but related to zsh, there's also https://github.com/jeffreytse/zsh-vi-mode/issues/316. I noticed this plugin was causing a lot of delay. Learned a decent amount about zsh profiling from that issue.
If your org doesn’t use mise, just add mise.toml to your global gitignore. Mise tries to be a single tool covering multiple needs, but don’t have to use it that way. I just manage toolchain versions and envvars (replace direnv).
The only thing I demand to be fast on my terminal is grep reverse search (ctrl+r) and of course typing a character. But if your terminal can't keep up with your typing speed there is something deeply wrong with it.
I don't remember when I did it, but it looks like I must have gone through this at some point (maybe due to using GNU Make a lot? Or perhaps it was some other tool) - my zsh setup does a bunch of autocomplete setup only in the interactive case, and it seems to help a bit with startup time, at least on macOS:
% for i in {1..5}; do /usr/bin/time zsh -i -c exit; done # zsh in interactive mode
0.05 real 0.03 user 0.02 sys
0.02 real 0.01 user 0.01 sys
0.02 real 0.01 user 0.00 sys
0.02 real 0.01 user 0.00 sys
0.02 real 0.01 user 0.00 sys
% for i in {1..5}; do /usr/bin/time zsh -c exit; done # zsh in non-interactive mode
0.01 real 0.00 user 0.01 sys
0.01 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
Developers that are very heavily invested in terminal and (over) optimize their terminal configuration are a small but very vocal minority.
I run a scrolling WM and have settled into a habit of opening terminals when I need them, then closing them right after. I'll open a terminal, git pull, close it. Etc. I also use a terminal that launches cold in 10-20 ms, so it's not like a pay a price for it.
This is actually what I thought this post was about! But then I saw the Ghostty reference, which, in my experience, is not very fast to launch at all. I got it opening new windows quickly by running the main process as a systemd service, but Foot launches way faster without all that fuss, and allows you to go the daemon route if you want it _even_ faster.
EDIT: Just want to clarify, no shade on Ghostty. That project is cross platform and uses the 100% defensible decision to use the full GTK stack on linux. Foot is Linux AND Wayland only, and uses that very restrictive environment to optimize the hell out of startup and general performance.
So much so that I vibe-coded my own terminal emulator for vertical tabs on macOS (using libghostty for the terminals) that is faster and less weird than iTerm.
That said, it is almost totally about the Z shell. So you might still qualify as 'weird' in this case on the alternative grounds of not using the Z shell. (-:
Apparently for some of the simplicity-produces-speed arguments, users have found complex/featurefull. tools that are still quick. I’m not sure how to evaluate this (I like simplicity just because it is easier to fit simple tools in my head) but we should note the counter argument (and applaud the follow-up).
You need to figure out what is going on because that certainly isn't normal.
Literally seeing 0.0% on Linux
I started using it expecting to love it, but in reality it didn't seem to gain me anything but in fact was worse in several major ways. Also less configurable than Iterm2. :/
I can't understand Ghostty either except as some kind of trendy memetic thing, the $GME of the TTY world.
In terms of speed, same thing: if you can provide some kind of objectively measurable thing, we can look into it. Everything we've measured so far firmly places Ghostty in the "fast" camp (with friends such as Kitty).
We're sometimes faster, sometimes slower, but in any case not noticeably so. You wouldn't pick Ghostty vs Kitty for example for performance, it'd be something else. But you would pick Ghostty over say... iTerm2 for performance (but you may pick iTerm2 for features, its extremely feature rich!).
$ for i in {1..5}; do /usr/bin/time zsh -i -c exit; done
0.01 real 0.00 user 0.00 sys
0.01 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sys
0.00 real 0.00 user 0.00 sysI had no idea that you could do that asynchronously, and then have ZSH update the already printed prompt with the status later! That blows my mind!
if [ "$SESSION_TYPE" != 'remote/ssh' ]; then
if [ "${TERM_PROGRAM}" != 'tmux' ]; then
( if [ $[RANDOM % 10] == "0" ]; then fortune -n 40 -s; else echo "Hi, $(whoami)!"; fi ) | cowsay | lolcat && printf '\n'
else
if [ "${TMUX_PANE}" == '%0' ]; then
fortune | cowsay -f small | lolcat && printf '\n'
fi
fi
fi
But what would life be without a little bit of fun?
— Kurt Vonnegut
Even with a low grade laptop, my zsh config grants me a sub 5ms prompt and a sub 1ms input lag, and that's far more important than the exit time.
./zsh-bench
==> benchmarking login shell of user XYZ ...
creates_tty=0
has_compsys=1
has_syntax_highlighting=0
has_autosuggestions=0
has_git_prompt=1
first_prompt_lag_ms=54.942
first_command_lag_ms=57.069
command_lag_ms=4.275
input_lag_ms=0.669
exit_time_ms=26.522
hyperfine --warmup 3 'zsh -i -c exit'
Benchmark 1: zsh -i -c exit
Time (mean ± σ): 26.5 ms ± 0.5 ms
Range (min … max): 25.5 ms … 27.6 ms"Most of these optimizations are about leaving stuff out. It's about being intentional and only adding things you're going to use."
I don't use X11 or a similar graphics layer, only textmode. Thus I don't use a terminal emulator
I don't use zsh. I use NetBSD sh
Smaller and faster
This is what I am comfortable with
Others may have their own preferences; to each their own
I might not understand others' preferences but that's their business, not mine
Yes you do. It's the one built into your operating system's kernel. You'll find a lot of, but not all of, its code in /usr/src/sys/dev/wscons .
"The terminal itself
Shell startup is only half the story, because the emulator adds its own input latency. I use Ghostty, which is GPU-accelerated and native, and my config is just seven lines long."
I do not use Ghostty or anything similar^1
1. https://en.wikipedia.org/wiki/List_of_terminal_emulators
Further, the terminal emulator cited by the blog author requires a graphics driver
I do not use a graphics driver
Yes you do. It's the one that your in-kernel terminal emulator talks to in order to splat its bitmap fonts onto the screen. It is whatever wsdisplay has attached to, which can be one of a range of things from genfb through voodoofb and machfb to radeonfb. There was even a vesafb about 20 years ago.
Maybe this is not clear. I apologise for any ambiguity
vga(4) can be referred to as a "graphics driver"
For example,
But it does not support (non-text) graphics
It only supports text
The blog author is using a graphics layer such as X11 or Wayland along with a terminal emulator such as Ghostty on top of it
I do not use those things
"VGA graphics driver"
"This driver handles VGA graphics..."
I only use VGA textmode
I do not context switch into a graphics mode via 13h. No need
The blog author mentions that his terminal emulator is "GPU-accelerated" ("GPU" stands for "Graphic Processing Unit")
I don't use a terminal emulator that requires a graphics mode or one that uses a GPU
I'm interested in "text processing", displaying text. I like reading
I'm not interested in displaying images
I do not use a "desktop" environment
As such, I do not need the dependencies of such terminal emulators, such as "gtk" ("GIMP ToolKit") a widget toolkit for creating GUIs ("Graphical User Interfaces")
As I am only using the command line, not a "desktop", I have no need for a GUI toolkit
The blog author is using more than the VGA driver to display text, as indicated by the reference to "GPU-accelerated"
1. Some call this a "graphics driver" while others state it "does not do graphics"
2. For example, drivers with names ending in "fb", such as "vesafb"
I use the vga driver which does not do graphics
The author of the blog post is using both (a) terminal emulator userland software and (b) kernel module(s) that perform terminal emulation
I only use one. I do not use a userland terminal emulator program
As it turns out, avoiding unnecessary fork() is good hygiene everywhere.
Kitty doesn't work, alacrity doesn't work, foot doesn't work, gnome terminal doesn't work, xfce terminal doesn't work, urxvt doesn't work, xterm doesn't work, the list goes on.