Debugging shell-startup latency while using Starship Prompt

Starship is a popular and versatile prompt management tool for the terminal. It enhances the shell experience by providing a customizable and feature-rich prompt. However, over time, I noticed that starting a new terminal session became increasingly slow. This post documents my journey in diagnosing and resolving this latency issue.

The Problem

After using Starship for a while, my terminal startup times became noticeably sluggish. Whenever I opened a new terminal window, I encountered the following warning message:

[WARN] - (starship::utils): You can set command_timeout in your config to a higher value to allow longer-running commands to keep executing.

Even after increasing the timeout as suggested, the issue persisted. This led me to investigate further.

Initial Investigation

When the shell starts up, the rc (run commands) files are evaluated. These files, such as .bashrc or .zshrc, contain configurations and commands that are executed every time a new terminal session is started. If your rc file includes a heavy or slow command, it can significantly slow down the terminal startup process.

Starship integrates with the shell startup process through this initialization sequence. For example, in the case of zsh, you add the following line to your .zshrc file:

eval "$(starship init zsh)"

This command initializes Starship and integrates it with the zsh shell lifecycle. Starship then executes various modules to build the prompt, which can contribute to startup time.

To identify the root cause of the slowdown, I used Starship’s built-in debugging command:

env STARSHIP_LOG=trace starship timings

This command provides a detailed timing summary of all the modules Starship runs in the background to render the prompt.

Analyzing the Output

Running the above command provides a detailed timing summary of all the modules that Starship executes in the background to render the prompt. Here is a sample output:

Here are the timings of modules in your prompt (>=1ms or output):
 git_status  -  29ms  -   "[?] "
 python      -  169ms  -   "via 🐍 pyenv system "
 directory   -   1ms  -   "hugo "
 git_branch  -  <1ms  -   "on  main "
 aws         -  <1ms  -   "on ☁️  (us-east-1) "
 gcloud      -  <1ms  -   "on ☁️  #redacted#(us-west1) "
 line_break  -  <1ms  -   "\n"
 character   -  <1ms  -   "➜ "

From the output, it was evident that the python module was significantly slower than the others, taking 169ms compared to the next highest module, git_status, which took 29ms.

The Quick Fix

To mitigate the delay, I decided to disable the python module in the Starship configuration. This can be done by editing the starship.toml file:

[python]
disabled = true

After making this change, the terminal startup time improved noticeably.

Ongoing Investigation

While disabling the python module provided an immediate speed boost, I am still looking for a more permanent solution that allows me to use the python prompt without the latency. The Starship community is actively discussing this issue on GitHub here for example.