[HN Gopher] Life is too short for a slow terminal
___________________________________________________________________
Life is too short for a slow terminal
Author : emschwartz
Score : 98 points
Date : 2026-06-06 12:44 UTC (2 days ago)
(HTM) web link (mijndertstuij.nl)
(TXT) w3m dump (mijndertstuij.nl)
| abejfehr wrote:
| I'm surprised people are still using nvm, considering it's impact
| on shell startup time.
|
| I can't recommend switching to mise highly enough:
| https://mise.en.dev/
| vstm wrote:
| I wasn't actually aware of the impact. I measured the zsh
| startup time locally (with mvn active and commented out) and it
| indeed makes a difference (.39s -> .08s). Not that I would have
| noticed that without measuring :) - yes I'm an old geezer.
|
| Thank you for the recommendation, I might then also be able to
| ditch sdkman as well.
| VorpalWay wrote:
| With zsh i set up nvm to lazy load, so I don't pay for it
| when I don't use it (I'm a C++ and Rust dev, but I
| occasionally need to run js stuff from other team members).
|
| 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.
| shhsshs wrote:
| I use aliases that lazily load nvm when I actually want to use
| it. This converts the shell startup penalty into a node/npm
| startup penalty.
| abejfehr wrote:
| This wasn't an option for us because as an org we used their
| recommended hook (1) to automatically change node versions
| when switching directories, but it effectively undoes the
| lazy loading.
|
| 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
| blfr wrote:
| How often do you launch a fresh terminal though? I start mine
| with a script to have favourite tabs ready at boot and then
| generally not much afterwards.
| skydhash wrote:
| For every query and commands. I don't use a DE, so pretty
| much everything is cli based. I use xterm and it's bound to
| mod4+Return for me.
| hombre_fatal wrote:
| Constantly. I think we've used the excuse of "well, what if
| you just launch it less often?" enough to excuse bad
| performance defaults, especially when alternative solutions
| fix the issue with very few trade-offs.
| frollogaston wrote:
| Maybe once a minute, though it's bursty so more like 4 times
| every 4 minutes, but I still didn't notice the nvm slowdown
| brewtide wrote:
| I set the framework key in function row to pop a new
| terminal. It's amazing.
| dawnerd wrote:
| I used to use volta but then they killed it and told people to
| switch to mise. The mise setup is just way too complicated. I
| just am tired of having different config files for different
| tooling when it should just read whats in the package.json and
| be done with it.
| bin_bash wrote:
| package.json config is supported
| https://mise.jdx.dev/lang/node.html#nvmrc-node-version-
| and-p...
| nickjj wrote:
| I had performance issues with Mise which I reported here
| https://github.com/jdx/mise/discussions/4821.
|
| 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.
| fg137 wrote:
| Life is too short to waste time on things that don't matter.
| binaryturtle wrote:
| Maybe I should remove the following bit of code from my
| profile? 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
|
| It's a whole chain of interpreters firing up (sub-shells, Perl
| for the cow, Ruby for the lol, I think.) :D
|
| But what would life be without a little bit of fun?
| titzer wrote:
| "I tell you, we are here on Earth to fart around and don't let
| anybody tell you any different."
|
| -- Kurt Vonnegut
| frollogaston wrote:
| 30ms is pretty slow $ 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 sys
| VladVladikoff wrote:
| Speaking of slow, what I absolutely cannot comprehend is why
| ghostty is so popular. Despite being written in Zig it is very
| slow and a total CPU and memory hog. Just sitting there idle it's
| pulling a constant 40% of my CPU? No thanks!
| esseph wrote:
| > Just sitting there idle it's pulling a constant 40% of my
| CPU? No thanks!
|
| You need to figure out what is going on because that certainly
| isn't normal.
|
| Literally seeing 0.0% on Linux
| liveoneggs wrote:
| My ghostty is using 0.4$ - 2.5%?
| Analemma_ wrote:
| I suspect you enabled some weird setting that you've forgotten
| about. ghostty isn't unimaginably fast but it's faster than
| iTerm 2 which is plenty. And I'm sitting here with a lengthy
| Claude Code session open, as well as a couple tabs for my
| docker container and dev servers, and its idle CPU usage is
| 0.0%.
| stavros wrote:
| That happened to me too, turns out my desktop was software
| accelerated because I had screwed up the GPU config somehow. I
| asked Claude to fix it and it did.
| saberience wrote:
| I know ghostty is designed to be super high performance but I
| find it both uglier and slower than Iterm2!
|
| 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. :/
| quotemstr wrote:
| WezTerm is great too and, AFAICT, is everything Ghostty wants
| to be. Kitty is also very good, although WezTerm edges it out
| for having an integrated muxer.
|
| I can't understand Ghostty either except as some kind of trendy
| memetic thing, the $GME of the TTY world.
| rewgs wrote:
| Yup. For a while I was switching between all three to see
| which I liked most, and I always end up coming back to
| Wezterm. The only issue I've encountered is that releases on
| various package managers are routinely broken, but building
| from source solved that.
| dismalaf wrote:
| This. Ghostty is significantly slower than Kitty on my Arch
| setup. It's still fast enough I guess, but no reason to switch
| from Kitty for me.
| mitchellh wrote:
| I'm the creator of Ghostty. This isn't right. It should idle at
| 0 to 1%, as supported by sibling comments. If you can collect
| more details about your system please open a discussion on the
| main Ghostty repo. Same with memory.
|
| 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!).
| DanielHB wrote:
| Am I the weird one? I usually have 3/4 terminals open at a time
| and rarely open new ones. Terminal startup speed is a non-issue
| for me.
|
| 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.
| fusslo wrote:
| I do the same, so there's a good chance you're (we're) the
| weird one
| tom_ wrote:
| It can affect shell subprocess startup time as well, which,
| depending on your setup and the tools you use, might be worth
| optimising for.
|
| 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
|
| For the interactive case, I don't really mind (within limits -
| the worst case, on macOS after a reboot, takes several seconds,
| and that's tedious). I also start new interactive terminal
| sessions fairly rarely.
| fg137 wrote:
| I'd say your workflow is pretty typical, from what I am seeing.
|
| Developers that are very heavily invested in terminal and
| (over) optimize their terminal configuration are a small but
| very vocal minority.
| frollogaston wrote:
| I only notice how efficient my terminal is if something dumps a
| ton of logs to stdout. Sure I can pipe to a file and use vim,
| but it's convenient not to need to do that. And sometimes I
| have like 8 things going at once.
| pkulak wrote:
| I open and close terminals _constantly_, but I'm usually pretty
| weird in my workflow, so no comment on your first question.
|
| 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.
| hombre_fatal wrote:
| I constantly open and close terminals too. Maybe I'm doing a
| quick lazygit check on cwd. Maybe I'm opening up an ephemeral
| claude/codex session for a couple questions about why a test
| failed. Or quickly editing a file with vim. Or remembering
| where I put that file with yazi or fzf. -- I don't even know,
| but all of it is contingent on it being fast to open a new
| terminal in cwd.
|
| 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.
| chickensong wrote:
| +1 for Foot, truly a joy to use.
| JdeBP wrote:
| Maybe, but notice that almost all of the article, and its
| followup posted today, is about the speed of starting a _shell_
| not of a _terminal emulator window_. So if you use interactive
| sub-shells, anything from shelling out of a vi clone or mailx,
| through :terminal in NeoVIM, to running tmux /screen or script,
| then the concerns are relevant.
|
| 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. (-:
| VorpalWay wrote:
| I open terminal far more often than that. But you should also
| remember that the startup cost is also paid by some subshells,
| and any shell scripts you run (the actual cost will vary: which
| init files are sourced varies between interactive and non-
| interactive shells as well as login shells and non-login
| shells, but it won't be zero cost).
| dopp0 wrote:
| > But if your terminal can't keep up with your typing speed
| there is something deeply wrong with it. For the poor sools
| that had to work in VDI with radio link...
| opan wrote:
| Same here. Main terminal w/ tmux, editor terminal with tmux
| (runs nvim so I can jump to it with a key bind), ssh to remote
| server with remote tmux, scratchpad term with tmux. I try to
| reuse the same panes a lot, otherwise open a new tmux window
| temporarily to do something (C-b c). Basically never open a
| whole new separate terminal instance on top of those.
| z3ugma wrote:
| Follow up / errata post written by the author today:
| https://mijndertstuij.nl/posts/what-i-got-wrong-about-fast-t...
| maherbeg wrote:
| Great post! There are some neat tricks around completion initing
| that I'll have to grab. I use fish shell and have done a bunch of
| optimization around async git statuses too.
| bee_rider wrote:
| I know nobody is missing it, because it is the first bit of the
| blog post, but the author does have a follow-up where they note
| corrections based on push-back they received from a reader.
|
| 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).
| quotemstr wrote:
| On Cygwin, FWIW, it pays _huge_ dividends to avoid making the
| shell fork at all costs. Don 't use $(sed ...). Use
| ${variable%foo%bar} or whatever. Cygwin punishes you hard for
| unnecessary fork().
|
| As it turns out, avoiding unnecessary fork() is good hygiene
| everywhere.
| turudjdj wrote:
| In my life I can spare 50ms waiting for an terminal. But I have
| no time to spend 10000000 ms commuting to work, cleaning poop
| after an animal, or waiting for partner to put their face on!
| anygivnthursday wrote:
| I read Ghostty runs in a single process, but whenever I tried
| something like that eg a client/server model in urxvt or foot, I
| ended up reverting, because eventually some weird state affected
| the daemon and had to restart it killing all my terminals, so
| nowdays I just run foot standalone, with sway tabbing and splits
| are kind of built into the wm anyways. But keep hearing about
| Ghostty and wondering if I am missing out on something.
| opan wrote:
| foot is great, I have yet to use anything better. I suspect
| Ghostty is aimed at part-time and full-time Mac users. I don't
| get the hype.
| 1vuio0pswjnm7 wrote:
| "The single biggest win is what's not there: no oh-my-zsh, no
| prezto or plugin manager. I've honestly never understood the
| appeal of these frameworks."
|
| "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
| JdeBP wrote:
| > Thus I don't use a terminal emulator.
|
| 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 .
| 1vuio0pswjnm7 wrote:
| I use the term "terminal emulator" in the same sense as in the
| blog post:
|
| "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
| acabal wrote:
| The gem in this post is Pure, which I haven't heard of until now.
| I also have my prompt show the git status, and for large repos
| `git status` can take 10+ seconds to load and cache.
|
| I 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!
| jhogendorn wrote:
| If you like that, you should check out my project
| https://beachcomber.sh . Its about time I take it from
| dogfooding to beta users if you want to give it a go.
| ilaksh wrote:
| Notice a lot of the article was about completions, which fish
| shell does better than zsh.
| idoubtit wrote:
| The problem with this article is that the benchmark method they
| use is flawed. The documentation of zshbench explains why:
| https://github.com/romkatv/zsh-bench
|
| 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 +-
| s): 26.5 ms +- 0.5 ms Range (min ... max):
| 25.5 ms ... 27.6 ms
| gguingff wrote:
| i honestly don't get why people think ghostty is fast. the gpu
| acceleration slows it down. maybe i push my machines harder than
| other people but when the machine is under load either gpu or cpu
| ghostty starts lagging super hard vs iterm. i've never had a
| problem with iterm render speed, but iterm never starts lagging
| when my box is fully maxed out and ghostty does regularly. i try
| it every few years and ive never seen any improvement.
| h4kunamata wrote:
| Life is too short to use slow and problematic system, Linux
| forever.
| tnelsond4 wrote:
| I was so disappointed that Ghostty doesn't properly render Khmer
| text. Abugidas are important and you have to be able to render
| the symbols non-linearly. Cosmic term is the only terminal I've
| seen that actually works. But it's a bit slow on my 14 year old
| laptop.
|
| 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.
| parlortricks wrote:
| I keep reading all these posts about terminal slowness, and here
| i am just sticking with Konsole + fish + starship.rs. Seems fine
| and responsive to me.
___________________________________________________________________
(page generated 2026-06-09 04:01 UTC)