Turns out my slowness was due to nvm being loaded on this line;

export NVM_DIR="$HOME/.nvm"
. "$(brew --prefix nvm)/nvm.sh"

I fixed this by using the following alias, and running loadnvm whenever I need it.

alias loadnvm=". /usr/local/opt/nvm/nvm.sh"

(thank you @mcornella for pointing out debug switches, doh!)

Mine is very very slow. When I open a terminal it takes about 7 seconds to launch the zsh and sometimes only half of the theme can display. What’s wrong with it after several updates?

Try running zsh in debug mode: zsh -xv and note where in the terminal freezes. If you use the asciinema tool you’ll be able to record it in real time and post it here. asciinema isn’t able to record time, it all just looks like a sequencial log with no pauses.

Cleaning the ASL logs (as described here) helps to reduce the startup time

A Debugging Technique

I didn’t read every post here, but I’m gonna post a technique for debugging slow startup just in case no one else has posted a good one yet.

If you install the moreutils package, you’ll have a timestamp command called ts. You can use it to print sub second resolution timestamps of all of the debug output from zsh that tell you how long since the last line of output. Then you can search that file for timestamps that are “long”. Here’s the command:

zsh -xv 2>&1 | ts -i "%.s" > zsh_startup.log

Just hit ‘ctrl-d’ when the prompt pops up to exit the debug shell, and you can then read ‘zsh_startup.log’ with whatever you want. It’ll be a long file, so find a good way to search it with regex. Keep in mind that zsh debug prints a line before running it, so the timestamps really tell you how long it took for the previous line to run, not the line the timestamp is currently on.

I used this search string in Vim to look for any command that took longer than a thousandth of a second: \M^\(0.000\)\@!. You can vary the number of zeros to search for the longest running lines first. E.g. To see which lines took longer than a second \M^\(0\)\@!.

Searching for lines taking longer than a second only found 1 line in my file, but that line took nearly one and a half seconds! Fixing that saved half the startup time that I was seeing.

Checking Your Progress

You may want to check your progress by looking for how many lines take longer than a given amount of time. If you’re a Vim user, you can use the substitution command in count only mode. E.g. :%s/\M^\(0.0\)\@!//n found that I had 7 lines that took longer than a tenth of a second to complete. Addressing just these 7 lines brought my zsh init time down from 4.13 sec to 0.87 sec!

That’s long compared to my bash which is 0.08 sec, but my zsh does so much more cool stuff, and I plan to look into some of the 26 lines that take more than a hundredth of a second at a later date.

Also, you may just want to see how long it’s taking to load without having to add up all those timestamps in the log file. I think I got this command from a post on this thread, but I’ll put it here for completeness:

/usr/bin/time /bin/zsh -i -c exit # reminder of last change

brew install moreutils call zsh -xv 2>&1 | ts -i "%.s" > zsh_startup.log sort by time sort --field-separator=' ' -r -k1 zsh_startup.log> sorted.log and see what loaded too slow. For me, it was a ruby plugin which needs a 3 second to loads

@nicohvi I also found that it was caused by the history.zsh file. I updated lines

HISTSIZE=10000
SAVEHIST=10000

to only be

HISTSIZE=1000
SAVEHIST=1000

It seems that the issue was that my .zsh_history file was almost 50k lines long with previous commands. Deleting that file also did the trick, though you’ll lose all command history you’ve had.

@samkugji you’ve killed the thread with your green mile, cut the crap

I knocked off about 3s, using this script by @Tyriar & @Stanzilla to defer loading of nvm:

# Defer initialization of nvm until nvm, node or a node-dependent command is
# run. Ensure this block is only run once if .bashrc gets sourced multiple times
# by checking whether __init_nvm is a function.
if [ -s "$HOME/.nvm/nvm.sh" ] && [ ! "$(whence -w __init_nvm)" = function ]; then
  export NVM_DIR="$HOME/.nvm"
  [ -s "$NVM_DIR/bash_completion" ] && . "$NVM_DIR/bash_completion"
  declare -a __node_commands=('nvm' 'node' 'npm' 'yarn' 'gulp' 'grunt' 'webpack')
  function __init_nvm() {
    for i in "${__node_commands[@]}"; do unalias $i; done
    . "$NVM_DIR"/nvm.sh
    unset __node_commands
    unset -f __init_nvm
  }
  for i in "${__node_commands[@]}"; do alias $i='__init_nvm && '$i; done
fi

Make sure you also remove nvm from the plugins list, and remove any other NVM loading code.

This has the benefit of auto-loading nvm the first time you try to run any of the commands in ('nvm' 'node' 'npm' 'yarn' 'gulp' 'grunt' 'webpack') 🎉

If you are using powerlevel9k, make the switch to powerlevel10k which is MUCH faster. I noticed a big speedup from wsl ubuntu 18.04 after switching from 9k to 10k.

I have the same insue with zsh in ubuntu in vagrant in a win 10 machine.

I install zsh and oh my zsh today is a really fresh installation.

all works fine out the project folder. with debug mode appears that:

+prompt_git:11> dirty=+prompt_git:11> parse_git_dirty
+parse_git_dirty:1> local 'STATUS='
+parse_git_dirty:2> local FLAGS
+parse_git_dirty:3> FLAGS=( --porcelain )
+parse_git_dirty:4> [[+parse_git_dirty:4> git config --get oh-my-zsh.hide-dirty
+parse_git_dirty:4> [[ '' != 1 ]]
+parse_git_dirty:5> [[ 1 -gt 0 ]]
+parse_git_dirty:6> FLAGS+='--ignore-submodules=dirty'
+parse_git_dirty:8> [[ '' == true ]]
+parse_git_dirty:11> STATUS=+parse_git_dirty:11> STATUS=+parse_git_dirty:11> git status --porcelain '--ignore-submodules=dirty'
+parse_git_dirty:11> tail -n1

and frezze the screem more less 30 sec.

I try to change agnoster to robbyrussell but the problem continue

I’m experiencing a similarly slow startup time to what @eduOS describes, 6-7 seconds to have a usable terminal 👎

Another profiling method to easily find slow plugins/themes/functions is zsh/zprof. Just add this to the top of your .zshrc and then run env ZSH_PROF= zsh -ic zprof:

if [[ -v ZSH_PROF ]]; then
  zmodload zsh/zprof
fi

(the conditional is just there so that normal sessions don’t have the profiler running in background)

edit: -v conditional only works from zsh 5.3 onwards (thanks @steinybot)

So put this at the top of your .zshrc instead

if [[ -n $ZSH_PROF ]]; then
  zmodload zsh/zprof
fi

and run with ZSH_PROF=1 zsh -ic zprof.

This might be unrelated, but I’m seeing the same on a fresh install of ohmysh on Ubuntu on Windows 10. Works like a charm on my OS X install btw, great job 👍

Zsh-version: 5.0.2 Ohmyzsh-version: latest

This is the entire content of my .zshrc:

ZSH=/home/<username>/.oh-my-zsh
source $ZSH/oh-my-zsh.sh

The shell takes about 7 seconds to load whenever I source ohmysh.sh.

Update After doing some more research, it’s the sourcing of config files that takes so long.

for config_file ($ZSH/lib/*.zsh);do
  custom_config_file="${ZSH_CUSTOM}/lib/${config_file:t}"
  [ -f "${custom_config_file" ] && config_file="${custom_config_file}
  source $config_file # this takes about six seconds
done

Update 2 It seems history.zsh might be the culprit. When I remove it from the lib folder the boot time goes down to about 2 seconds (which I can live with).

If you use aws plugin , comment out brew invocation in :

.oh-my-zsh/plugins/aws/aws.plugin.zsh

_awscli-homebrew-installed() {
#  brew list awscli &> /dev/null
 true
} 

AND add false to

_homebrew-installed() {
  type brew &> /dev/null
  false
}

So even if you have brew installed ( probably good idea anyway ) , you will save 2 invocations of

brew --prefix awscli and brew list awscli

$ time zsh -xv -c exit
exit
+zsh:1> exit
zsh -xv -c exit  0.00s user 0.00s system 55% cpu 0.006 total

My plugins

plugins=(zsh-autosuggestions brew aws kitchen knife osx ruby docker colorize vagrant zsh-syntax-highlighting sudo)

yup lazy loading is also a way to do it, but it might still screw with your performance. For example if you use neovim or other editors with certain extensions. Basically everything that spawns a new shell will suck 😕 . Apart from that it should work, for me my hard fork works just perfect and has also eliminated almost all the overhead and loadtime which have been the problem.

https://github.com/wzrdtales/nvm-ng

Small benchmarks of the improvement are here:

https://github.com/wzrdtales/nvm-ng/issues/2

and load it with (the --fast-reuse bit makes the biggest improvement though)

[[ -f "$NVM_DIR/nvm.sh" ]] && source "$NVM_DIR/nvm.sh" --fast-reuse

Or just manually pull the plugin https://github.com/robbyrussell/oh-my-zsh/pull/6671 and use it.

It is still very sad that the author of nvm is not really willing to replace the very slow npm call which is the reason of all evil with a simple sed. However. all the solutions here should help.

not sure this is relevant or not but my slowdown comes from git checks. For example just typing cd unrealengine into my unreal engine repo folder took 25 seconds. Using zsh -xv as pointed out above, all the time was spent in

git diff --no-ext-diff '--ignore-submodules=dirty' --quiet --exit-code

Whatever it’s doing is cached because the next time I visit the folder there’s no big pause.

Thanks @johnp that was a nice suggestion. Although for some odd reason my oh-my-zsh does not seem to understand the -v conditional.

⚡ echo $SHELL
/bin/zsh
⚡ if [[ -v SHELL ]]; then
then> echo "yup"
then> else
else> echo "nope"
else> fi
zsh: unknown condition: -v

No idea what is up with that but I just took the conditional out (for now) and zprof worked extremely well.

Here is the culprit in my case:

       1/1     18739.57 18739.57   78.54%  18739.57 18739.57             compinit [2]
 1)    1       18739.57 18739.57   78.54%  18739.57 18739.57   78.54%  compdump

On closer inspection I had a whole bunch of .zcompdump* files from about a month or so ago so I got rid of them and it was much faster after that.

oh-my-zsh is slow on folders with git while fast in other regular folders, we got rid of this issue using:

git config oh-my-zsh.hide-status 1 --global

this will disable the Git status prompt in all repositories you have on your machine

Now if I do something like ls the output is immediate, it’s unfortunate to not see the git status but a fast terminal is more important than this 😃

source of the command above: https://www.stevenrombauts.be/2018/04/disable-git-prompt-in-oh-my-zsh/ (thanks to the author)

@foxx Thanks man, I was going crazy with this problem, mine was almost taking 8-10 seconds to load terminal and new tabs and finally creating alias to manually load nvm and removing old lines worked for me

Small tips though, looking at the auto generated code we can also use $(brew --prefix nvm)/nvm.sh

# export NVM_DIR=~/.nvm
# source $(brew --prefix nvm)/nvm.sh

alias loadnvm=". $(brew --prefix nvm)/nvm.sh"

This did fixed my problem with load time, thanks

@ShawnLinLoveLife that’s a powerline thing. Have a look at their documentation for potential improvements: http://powerline.readthedocs.io/en/latest/troubleshooting.html?highlight=zpython#i-am-suffering-bad-lags-before-displaying-shell-prompt.

Thanks for your fast reply. I figured out, that “command-not-found” really slows down the start of zsh (on opening new shell), so I removed it as it does not have this overvalue. I also found out, that there is a difference running zsh “normaly” or after sourcing the .zshrc. It takes about double time after resourcing the file.

You cann see the asciinema-video here: https://asciinema.org/a/9h3kd6ngpxnosmdi5ra3totgc

This worked for me. With macOS Big Sur 11.3, Xcode 12.5, Command Line Tools, and iTerm2 fresh installation.

1. Uninstall oh-my-zsh

Instructions here.

2. Install homebrew

Instructions here.

3. Install git (but with homebrew)

brew install git

4. Install oh-my-zsh again

Instructions here.

That’s all!

In my case, the thing was that when I installed the Command Line Tools, a git version was installed. And apparently there is an issue between that git version and oh-my-zsh. That was causing a slow startup with the xcodebuild title in the iTerm2 window.

There’s also this zsh plugin for nvm which I have been using for some time https://github.com/lukechilds/zsh-nvm

What I did worked for reducing time consumption at initial startup.

What I did is that, I edited oh-my-zsh.sh in .oh-my-zsh folder and commented the all the lines which check for updates. i.e., these lines Check for updates on initial load… #if [ “$DISABLE_AUTO_UPDATE” != “true” ]; then # env ZSH=$ZSH DISABLE_UPDATE_PROMPT=$DISABLE_UPDATE_PROMPT zsh -f $ZSH/tools/check_for_upgrade.sh #fi and the terminal initialises right at the startup without any time

Heres a better solution that still lets you call node and npm:

https://github.com/creationix/nvm/issues/539#issuecomment-245791291

Hmm, not really as it is still slow. What do you say to the benchmark time without plugins? Is it normal?

What about the fact, that benchmark takes double time after sourcing “.zshrc”?

After investigating, this triggered the issue xcodebuild: export SDKROOT=$(xcrun -sdk macosx --show-sdk-path).

Solution is by running sudo xcode-select -s /Library/Developer/CommandLineTools as mentioned in here

So this is not problem of omz. Correction: My bad i have nvm installed as well but it does not trigger issue.

Another finding during investigation is to get brew path using brew --prefix <formula> requires ruby. Change to absolute path make it faster.

command-not-found is really really slow to init.

The issue in my case was the vcs_info which checks the version control status of the current working directory.

1- I’ve replaced the following line in my active theme redefined.sh-theme under .oh-my-zsh/themes folder:

command git diff --quiet --ignore-submodules HEAD &>/dev/null; [ $? -eq 1 ] && echo "*"

to

git diff-files --no-ext-diff --quiet || git diff-index --no-ext-diff --quiet --cached HEAD

(This is only good unless you want to take untracked files into account)

2- Set the DISABLE_UNTRACKED_FILES_DIRTY="true" in my .zshrc 3- Ran git config oh-my-zsh.hide-status 1 on the most complicated repo I’d visit at most

By the way, thanks guys for pointing out, zsh -xv helped me a lot to find the problematic line.

Now, switching into folders with complicated repos is much faster.

zsh -xv > ~/info 2>&1

I met the same issue, there were xcode 9.0 and xcode 8.2 in my osx. once openning iterm2, the title bar occured (xcodebuild), so I uninstall xcode 8.2. Luckily, it works fine

Hello, same issue. it runs about 10 second and ~6 seconds for each command. Commenting all in .oh-my-zsh/lib/history.zsh fixed that.

I find the solution if git_prompt_info slow

git config --global oh-my-zsh.hide-status 1

1. disable that function in ~/.zshrc

git_prompt_info() {}

For me on the latest OSX prompt randomly slowed down due to an excess of .asl files slowing me down and following this link to remove them fixed it.

http://osxdaily.com/2010/05/06/speed-up-a-slow-terminal-by-clearing-log-files/