Live data from Hacker News

Life is too short for a slow terminal

mijndertstuij.nl

61–70 of 98 posts

Re: Life is too short for a slow terminal

#61

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.

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. (-:

Re: Life is too short for a slow terminal

#62

"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 Smalle…

> 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 .

Re: Life is too short for a slow terminal

#63
post #57

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.

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 thi…

+1 for Foot, truly a joy to use.

Re: Life is too short for a slow terminal

#64

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/

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.

Re: Life is too short for a slow terminal

#65

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/

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.

Re: Life is too short for a slow terminal

#66
post #19

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/

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.

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.

Re: Life is too short for a slow terminal

#67

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.

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).

Re: Life is too short for a slow terminal

#68

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.

> 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...

Re: Life is too short for a slow terminal

#70
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 ± σ):      26.5 ms ±   0.5 ms
      Range (min … max):    25.5 ms …  27.6 ms
Post reply on HN