Opening a new terminal tab takes roughly two seconds before the zsh prompt appears. How would you find out what part of the startup is slow, and what typically turns out to be responsible?

## Measure before you touch anything Shell startup is the one latency everybody feels and almost nobody measures. Get a number first. ```zsh for i in 1 2 3; do time zsh -i -c exit; done ``` Run it several times — the first run pays cold-cache costs that are not representative. Then establish the floor: ```zsh time zsh -f -i -c exit ``` `-f` skips the startup files, so this is zsh itself with nothing of yours. If the two numbers are close, the slowness is not your configuration at all and you should be looking elsewhere — a slow terminal emulator, a network home directory, a machine-wide file under `/etc`. If the gap is 1.9 of your 2 seconds, keep going. ## zprof zsh ships a profiler as a loadable module. Wire it around the file you suspect: ```zsh # first line of ~/.zshrc zmodload zsh/zprof # ...everything else... # last line of ~/.zshrc zprof ``` Open a new interactive shell (`zsh -i -c exit` will do) and you get a table: number of calls, total time, average, self time, and the function name, sorted with the expensive things at the top. Two columns matter. **Total** time includes everything a function called; **self** time is what the function burned itself. A wrapper with large total and tiny self time is innocent — follow the callee. The important limitation: `zprof` profiles **shell functions**. Straight-line code at the top level of your rc file, and much of what a plain `source` of someone else's script does, is not attributed to any function and can hide from the report. If `zprof` shows a total far below your measured wall time, the missing time is exactly that kind of code, and bisection is how you find it. ## Bisection, the technique that always works Comment out the bottom half of `~/.zshrc`, re-measure, and keep halving. It feels crude next to a profiler and it is strictly more reliable, because it measures the thing you actually care about — wall-clock time to prompt — rather than a model of it. Ten minutes of halving localises almost any startup problem to a single line. ## What it usually turns out to be Across real configurations the same offenders recur: - **Version-manager initialisation.** Lines of the form `eval "$(sometool init -)"` fork a process, wait for it to print shell code, and then evaluate that code — on every shell you open. Some managers additionally source a large shell library. This is very often the single biggest item in the report. - **Eagerly loaded plugins.** A plugin manager that sources twenty repositories at startup pays for twenty repositories at startup, whether or not you use them today. - **Any `$(...)` in the file.** Each one is a fork. Querying a tool for a path you could have written literally is a per-shell tax for a value that changes twice a year. - **The completion system's initialisation**, when it is made to rebuild rather than use its cache. - **Anything that touches the network.** A version check, a remote lookup, a status query. On a good day it is 200 ms; on a bad day your terminal hangs. ## Fixing, in order of preference 1. **Delete it.** A surprising share of a slow rc file is configuration for tools the person no longer uses. 2. **Make it literal.** Replace a `$(...)` that computes a stable path with the path. 3. **Defer it.** Load the expensive thing the first time it is actually needed rather than at startup. Plugin managers offer this directly: zinit's `wait` ice (its turbo mode) schedules a plugin to load shortly after the prompt appears, and antidote takes a different route by generating one static file from your plugin list which the rc file simply sources. 4. **Move it.** Anything only login shells need belongs in `~/.zprofile`, not in the file every tab reads. ## Hiding it is not fixing it Some prompt frameworks offer an "instant prompt" that draws a usable prompt immediately and finishes initialising behind it. That genuinely improves the experience, and it is worth having — but the work still happens, it still delays the first command in a scripted context, and it can mask a configuration that has quietly grown to three seconds. Measure with the feature disabled at least once so you know the real number you are hiding. ## Set a budget The practical bar is that a new tab should feel instant — under about 100 ms of your own configuration. Treat that as a budget and re-measure after adding anything to the file. Startup time is like a spending habit: it never gets slow in one commit, it gets slow in forty.