5 ms·

every time your shell takes 100ms to render git status that you didn’t even need, you're paying invisible tax on flow. terminals should be reactive memory tools

every time your shell takes 100ms to render git status that you didn’t even need, you're paying invisible tax on flow. terminals should be reactive memory tools, not passive decoration. we optimize for code runtime but not for our own typing latency

Twirrim 1y ago
Starship is very fast, taking only a couple of milliseconds to gather the data (and you can easily configure it to minimise what it'll spend time gathering). It's night and day compared to other ones I've tried, where the hundred millisecond-ish delays annoyed me.
- Night_Thastus 1y ago
  Depends a lot on the system. I tried using it on Windows via MSYS2, and it seems like some Windows overhead (maybe process startup?) was causing Starship to slow it all down to a crawl. Disabling a few of the addons helped but didn't fix it. In the end I stopped using it.
  - lukeschlather 1y ago
    I don't know if Windows can be helped. It may be antivirus but I feel like 50th percentile load time is at least a second and there's nothing to be done about it. git just hangs sometimes on git show/git diff. I have to kill the terminal.
    - WorldMaker 1y ago
      My experience of Starship on Windows has been great. I'm using the Windows native builds of both Starship and git (both installed/updated via winget these days) in PowerShell. I try to avoid emulation layers like MSYS2, as much as I'm able. Also, yes, if git hangs on git show/git diff that sounds like an antivirus problem or a dying hard drive or the first one causing the other one.
      - Twirrim 1y ago
        Or just a really big git repo. Starship includes a timings command, on linux (with an annoying antivirus meddling) this is what I see against one directory: git_status - 6ms - "[!?] " directory - 4ms - "<redacted> " python - 3ms - "via v3.12.9 (.venv) " character - <1ms - " " git_branch - <1ms - "on  main " hostname - <1ms - "<redacted> in " If I go in to my checked out version of the linux kernel, probably the biggest git project I've got kicking around: git_status - 115ms - "" directory - 4ms - "linux " character - <1ms - " " git_branch - <1ms - "on  master " hostname - <1ms - "<redacted> in " That's typically the worst I see it.
        WorldMaker 1y ago
        I appreciate Starship also has configurable limits on those timings, too. I've almost never seen Starship hang for very long, as it will just drop the thing that is slow. I sometimes but rarely (usually just starting a new shell, but sometimes if compiling in another window/terminal) see the "[WARN] Executing command git timed out" error and the git_status won't display until the next prompt and that is usually fine.
  - pxc 1y ago
    Windows' filesystem performance for tools that expect Unix is abysmal, and it gets drastically worse in most corporate environments because endpoint security software hooks into the filesystem drivers to instrument all file access. Git-aware prompts can't be recommended on Windows, imo.
- eddd-ddde 1y ago
  100ms to render a prompt are meaningless. You can just type commands and run them asynchronously. I do this all the time when a previous command is taking a little extra to complete but I already know what my next command is going to be.
bregma 1y ago
If you're used to, say, VS Code or the GitHub online editor where the lag between pressing a key on the keyboard and a corresponding character appearing on the screen can be on the order of tens of thousands of milliseconds, then 100 ms will seem like lightning.
- dminik 1y ago
  There's a thousand milliseconds in a second. If your VSCode is taking +10 seconds to display a single character, it might be time to upgrade from your Commodore 64.
  - falcor84 1y ago
    Or to switch from VSCode to SpeedScript
  - gapan 1y ago
    Well, actually, the Commodore 64 is a lot faster with respect to input latency than any modern machine.
OptionX 1y ago
we optimize for code runtime but not for our own typing latency 100ms optimization is a lot different for a CPU or a human brain. I'm not defending having the entire system log dumped out on every prompt but a few amenities are worth a few milliseconds computation time for a human. Besides, I don't see how, for example , having your prompt take those 100ms to print a git branch or status breaks your "flow" yet having to type out the commands yourself and taking longer doing it doesn't. Its a balance between bloat and and usability like so many other things, but, to me at least, being on either extreme of bloat or extreme-minimalism seems counterproductive.
- naniwaduni 1y ago
  100 ms is an incredibly long time even for humans.
infogulch 1y ago
Could prompt tools like this use TUI-style features to edit the displayed prompt after releasing it back to the user? So if kubectl, git, or aws cli takes 200ms to finish it doesn't matter, the data from the output of these commands will appear a few moments after the prompt has been released to the user, so the user doesn't feel like they're waiting for the prompt to be ready.
gobblegobble2 1y ago
The delay is certainly frustrating. I use a patched version of kitty terminal that moves starship prompt to the bottom of the window, similar to vim and emacs. Since modeline updates are asynchronous, the shell prompt is very snappy even in big git repos. The downside is that you have to patch kitty and I never bothered to test my personal pet project on anything else than Linux. https://github.com/mbachry/kitty-modeline https://github.com/mbachry/kitty-modeline
perrygeo 1y ago
counter-point: having to constantly track git status in your head, and needing to type commands to remind yourself, is a far bigger distraction. Optimize to avoid context switching, not for a few ms latency. FWIW, I switched from zsh default to starship and didn't notice any perceptible difference. But I certainly notice when I mess up my git commits!
account42 1y ago
> we optimize for code runtime but not for our own typing latency Don't the layers of frameworks mean that the opposite is true.

Twirrim 1y ago

Starship is very fast, taking only a couple of milliseconds to gather the data (and you can easily configure it to minimise what it'll spend time gathering). It's night and day compared to other ones I've tried, where the hundred millisecond-ish delays annoyed me.

Night_Thastus 1y ago
Depends a lot on the system. I tried using it on Windows via MSYS2, and it seems like some Windows overhead (maybe process startup?) was causing Starship to slow it all down to a crawl. Disabling a few of the addons helped but didn't fix it. In the end I stopped using it.
- lukeschlather 1y ago
  I don't know if Windows can be helped. It may be antivirus but I feel like 50th percentile load time is at least a second and there's nothing to be done about it. git just hangs sometimes on git show/git diff. I have to kill the terminal.
  - WorldMaker 1y ago
    My experience of Starship on Windows has been great. I'm using the Windows native builds of both Starship and git (both installed/updated via winget these days) in PowerShell. I try to avoid emulation layers like MSYS2, as much as I'm able. Also, yes, if git hangs on git show/git diff that sounds like an antivirus problem or a dying hard drive or the first one causing the other one.
    - Twirrim 1y ago
      Or just a really big git repo. Starship includes a timings command, on linux (with an annoying antivirus meddling) this is what I see against one directory: git_status - 6ms - "[!?] " directory - 4ms - "<redacted> " python - 3ms - "via v3.12.9 (.venv) " character - <1ms - " " git_branch - <1ms - "on  main " hostname - <1ms - "<redacted> in " If I go in to my checked out version of the linux kernel, probably the biggest git project I've got kicking around: git_status - 115ms - "" directory - 4ms - "linux " character - <1ms - " " git_branch - <1ms - "on  master " hostname - <1ms - "<redacted> in " That's typically the worst I see it.
      - WorldMaker 1y ago
        I appreciate Starship also has configurable limits on those timings, too. I've almost never seen Starship hang for very long, as it will just drop the thing that is slow. I sometimes but rarely (usually just starting a new shell, but sometimes if compiling in another window/terminal) see the "[WARN] Executing command git timed out" error and the git_status won't display until the next prompt and that is usually fine.
- pxc 1y ago
  Windows' filesystem performance for tools that expect Unix is abysmal, and it gets drastically worse in most corporate environments because endpoint security software hooks into the filesystem drivers to instrument all file access. Git-aware prompts can't be recommended on Windows, imo.
eddd-ddde 1y ago
100ms to render a prompt are meaningless. You can just type commands and run them asynchronously. I do this all the time when a previous command is taking a little extra to complete but I already know what my next command is going to be.

bregma 1y ago

If you're used to, say, VS Code or the GitHub online editor where the lag between pressing a key on the keyboard and a corresponding character appearing on the screen can be on the order of tens of thousands of milliseconds, then 100 ms will seem like lightning.

dminik 1y ago
There's a thousand milliseconds in a second. If your VSCode is taking +10 seconds to display a single character, it might be time to upgrade from your Commodore 64.
- falcor84 1y ago
  Or to switch from VSCode to SpeedScript
- gapan 1y ago
  Well, actually, the Commodore 64 is a lot faster with respect to input latency than any modern machine.

OptionX 1y ago

we optimize for code runtime but not for our own typing latency 100ms optimization is a lot different for a CPU or a human brain. I'm not defending having the entire system log dumped out on every prompt but a few amenities are worth a few milliseconds computation time for a human. Besides, I don't see how, for example , having your prompt take those 100ms to print a git branch or status breaks your "flow" yet having to type out the commands yourself and taking longer doing it doesn't. Its a balance between bloat and and usability like so many other things, but, to me at least, being on either extreme of bloat or extreme-minimalism seems counterproductive.

naniwaduni 1y ago
100 ms is an incredibly long time even for humans.

infogulch 1y ago

Could prompt tools like this use TUI-style features to edit the displayed prompt after releasing it back to the user? So if kubectl, git, or aws cli takes 200ms to finish it doesn't matter, the data from the output of these commands will appear a few moments after the prompt has been released to the user, so the user doesn't feel like they're waiting for the prompt to be ready.

gobblegobble2 1y ago

The delay is certainly frustrating. I use a patched version of kitty terminal that moves starship prompt to the bottom of the window, similar to vim and emacs. Since modeline updates are asynchronous, the shell prompt is very snappy even in big git repos. The downside is that you have to patch kitty and I never bothered to test my personal pet project on anything else than Linux. https://github.com/mbachry/kitty-modeline https://github.com/mbachry/kitty-modeline

perrygeo 1y ago

counter-point: having to constantly track git status in your head, and needing to type commands to remind yourself, is a far bigger distraction. Optimize to avoid context switching, not for a few ms latency. FWIW, I switched from zsh default to starship and didn't notice any perceptible difference. But I certainly notice when I mess up my git commits!

account42 1y ago

> we optimize for code runtime but not for our own typing latency Don't the layers of frameworks mean that the opposite is true.