4 ms·

Does the speed of your shell matter? Surely the speed of the programs that you're running through your shell matter more. I've never been let down by how fast b

Does the speed of your shell matter? Surely the speed of the programs that you're running through your shell matter more. I've never been let down by how fast bash can tell a program to start running EDIT: oh, i misunderstood, its just the prompt at the start of your shell... I dont think ive ever been annoyed at how fast that renders either

mlenz 1y ago
In this case it‘s about the actual startup time of your shell. When launching a new terminal, starship always need to perform its initialization. If it were slow, I wouldn’t use it because waiting seconds before being able to input anything is kind of annoying. That‘s what they’re referring to.
danpalmer 1y ago
Some people like to put, for example, their current git branch in the prompt. To get that means at least naively, running a git command on every single line the prompt renders on. Git is fast, but it's easy to add a bunch of these and suddenly your prompt takes 100ms to render. Hit enter a few times and you'll immediately notice lag. For that reason, doing this fast does make a real difference. Of course the fastest thing is to just not stuff your prompt full of detail.
- blueflow 1y ago
  If you do not have any subshells or command substitutions in your PS1, then you also save alot of time on platforms like WSL, where forks are expensive.
  - partdavid 1y ago
    My earliest background as a shell user was as as system administrator (back in "the day", let's say), and forks are always potentially expensive, and often the reason you're opening a shell session in the first place (to diagnose resource contention or exhaustion, for example). There have been lots of times when one more fork is too much to take. (Which also, yes, makes it "interesting" to figure out what you can run in your shell session, too).
- account42 1y ago
  > Git is fast, but it's easy to add a bunch of these and suddenly your prompt takes 100ms to render. Or maybe many seconds if you have network drives over a slow VPN connection - not working on network drives, just having them connected. Fun to diagnose when you need to get urgent work done while traveling.
- WhyNotHugo 1y ago
  Even 'git status' gets slow on large repositories (or slow hosts). git status takes 643ms for github.com/rust-lang/rust
- partdavid 1y ago
  A non-forking prompt command is an absolute requirement for me and always has been, so I did this in pure shell. It's not a lot of code but it's a little tricksy. If I still used bash, starship would be a non-starter for me, in part, since it's fork/execed in the prompt command. Further up this thread someone says that the zsh installation is different and it's a native shared library that gets loaded into zsh. That seems neat. (The other reason it's a non-starter is that maybe I can stomach sending over a dotfile to various systems, but selecting a platform-specific native binary is too much configuration management to be done to prepare for an SSH session/kubectl exec. Eventually I made my peace with doing this for emacsclient so I could have local editing of remote files, but that's a lot less critical of a piece to miss than something that appears in your prompt. Conceptually, if you want to ship over/config-manage a native binary, you might as well install a better shell, which became a compelling argument to me when I switched to Powershell).
goriv 1y ago
I used to use spaceship prompt before this, and it would often take 5s to open up a new terminal and wait for the prompt to load, starship is always instant (like a prompt should be).
Twirrim 1y ago
Every single time your prompt appears, your shell is doing something. I've tried using various prompt customising things in the past, but they've almost all been written in shell, and always been palpably slow. To the degree that I've found it irritating and stopped using them. Starship is the first one that hasn't irritated me, in no small part because it's lightning fast, typically only couple of milliseconds to gather and render the prompt. This is the first time I've been able to stick with one.
WhyNotHugo 1y ago
I've tried tools in this space which add hundreds of milliseconds to a shell's start-up time. That's easily noticeable, especially when the system is under heavy load.

mlenz 1y ago

In this case it‘s about the actual startup time of your shell. When launching a new terminal, starship always need to perform its initialization. If it were slow, I wouldn’t use it because waiting seconds before being able to input anything is kind of annoying. That‘s what they’re referring to.

danpalmer 1y ago

Some people like to put, for example, their current git branch in the prompt. To get that means at least naively, running a git command on every single line the prompt renders on. Git is fast, but it's easy to add a bunch of these and suddenly your prompt takes 100ms to render. Hit enter a few times and you'll immediately notice lag. For that reason, doing this fast does make a real difference. Of course the fastest thing is to just not stuff your prompt full of detail.

blueflow 1y ago
If you do not have any subshells or command substitutions in your PS1, then you also save alot of time on platforms like WSL, where forks are expensive.
- partdavid 1y ago
  My earliest background as a shell user was as as system administrator (back in "the day", let's say), and forks are always potentially expensive, and often the reason you're opening a shell session in the first place (to diagnose resource contention or exhaustion, for example). There have been lots of times when one more fork is too much to take. (Which also, yes, makes it "interesting" to figure out what you can run in your shell session, too).
account42 1y ago
> Git is fast, but it's easy to add a bunch of these and suddenly your prompt takes 100ms to render. Or maybe many seconds if you have network drives over a slow VPN connection - not working on network drives, just having them connected. Fun to diagnose when you need to get urgent work done while traveling.
WhyNotHugo 1y ago
Even 'git status' gets slow on large repositories (or slow hosts). git status takes 643ms for github.com/rust-lang/rust
partdavid 1y ago
A non-forking prompt command is an absolute requirement for me and always has been, so I did this in pure shell. It's not a lot of code but it's a little tricksy. If I still used bash, starship would be a non-starter for me, in part, since it's fork/execed in the prompt command. Further up this thread someone says that the zsh installation is different and it's a native shared library that gets loaded into zsh. That seems neat. (The other reason it's a non-starter is that maybe I can stomach sending over a dotfile to various systems, but selecting a platform-specific native binary is too much configuration management to be done to prepare for an SSH session/kubectl exec. Eventually I made my peace with doing this for emacsclient so I could have local editing of remote files, but that's a lot less critical of a piece to miss than something that appears in your prompt. Conceptually, if you want to ship over/config-manage a native binary, you might as well install a better shell, which became a compelling argument to me when I switched to Powershell).

goriv 1y ago

I used to use spaceship prompt before this, and it would often take 5s to open up a new terminal and wait for the prompt to load, starship is always instant (like a prompt should be).

Twirrim 1y ago

Every single time your prompt appears, your shell is doing something. I've tried using various prompt customising things in the past, but they've almost all been written in shell, and always been palpably slow. To the degree that I've found it irritating and stopped using them. Starship is the first one that hasn't irritated me, in no small part because it's lightning fast, typically only couple of milliseconds to gather and render the prompt. This is the first time I've been able to stick with one.

WhyNotHugo 1y ago

I've tried tools in this space which add hundreds of milliseconds to a shell's start-up time. That's easily noticeable, especially when the system is under heavy load.