New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oh-my-zsh very slow :( #5327

Closed
SebTM opened this Issue Aug 20, 2016 · 60 comments

Comments

Projects
None yet
@SebTM

SebTM commented Aug 20, 2016

Hello,

I'm new to zsh/oh-my-zsh and installed it the first time on Mac OS X today. My Terminal (iTerm2 and default Mac-Terminal) starts very slow now - I have a real "waiting" time after opening App. Inside the Terminal it's better but also compared to "default bash" - slow. For example, if I only push the enter-key it just takes 1-2 seconds before terminal "responds", or if I press "CMD+V" for paste, I have to wait some seconds.

Used software:

  • Mac OS X - 10.11.6 (El Capitan)
  • ZSH v5.2
  • oh-my-zsh - latest (installed today)

Benchmark (with plugins - see .zshrc - loaded):

/usr/bin/time /usr/local/bin/zsh -i -c exit
4.63 real 0.47 user 0.29 sys

Benachmark (without plugins loaded):

/usr/bin/time /usr/local/bin/zsh -i -c exit
1.38 real 0.24 user 0.13 sys

Here also my ".zshrc"-file:

# Path to your oh-my-zsh installation.
export ZSH=/Users/username/.oh-my-zsh

# Set name of the theme to load.
ZSH_THEME="agnoster"

# Which plugins would you like to load? (plugins can be found in ~/.oh-my-zsh/plugins/*)
plugins=(git command-not-found copydir copyfile cp history sublime vagrant composer symfony brew osx)

source $ZSH/oh-my-zsh.sh

# Set default-user to remove "user@hostname" from agnoster
DEFAULT_USER="username"

# Load zsh-syntax-highlighting
source /usr/local/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

# Set correct path for php-5.6
export PATH=/usr/local/php5-5.6.23-20160626-132038/bin:~/.composer/vendor/bin/:$PATH

Is this normal or can it be fixed?

@mcornella

This comment has been minimized.

Collaborator

mcornella commented Aug 20, 2016

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.

@SebTM

This comment has been minimized.

SebTM commented Aug 20, 2016

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

@allanburleson

This comment has been minimized.

allanburleson commented Aug 21, 2016

I believe you want to close this if you figured out the problem?

@SebTM

This comment has been minimized.

SebTM commented Aug 21, 2016

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"?

@eduOS

This comment has been minimized.

eduOS commented Aug 31, 2016

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?

@cewood

This comment has been minimized.

cewood commented Sep 7, 2016

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

@yorch

This comment has been minimized.

yorch commented Sep 8, 2016

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

@foxx

This comment has been minimized.

foxx commented Sep 22, 2016

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!)

@SebTM

This comment has been minimized.

SebTM commented Sep 22, 2016

So is it fixed - or how can I fix it on my device?

@foxx

This comment has been minimized.

foxx commented Sep 22, 2016

@SebTM can you paste a copy of your .zshrc please? Also can you try with a clean .zshrc and then also with a fresh install of ohmyzsh? This should at least help narrow down where the problem might be

@nicohvi

This comment has been minimized.

nicohvi commented Sep 29, 2016

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).

@ShawnLinLoveLife

This comment has been minimized.

ShawnLinLoveLife commented Oct 7, 2016

# Path to your oh-my-zsh installation.
export ZSH=/Users/shawn/.oh-my-zsh

ZSH_THEME="agnoster"

plugins=(git)

source $ZSH/oh-my-zsh.sh

# User configuration

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
. /usr/local/lib/python2.7/site-packages/powerline/bindings/zsh/powerline.zsh

This is my zshrc, and I think it is the last line that makes it slowly. Any suggestions? Thanks!

. /usr/local/lib/python2.7/site-packages/powerline/bindings/zsh/powerline.zsh
@mcornella

This comment has been minimized.

Collaborator

mcornella commented Oct 10, 2016

@mcornella

This comment has been minimized.

Collaborator

mcornella commented Oct 10, 2016

@nicohvi can you try debugging where in the file it slows down? If you run set -xv; source $ZSH/lib/history.zsh; set +xv you'll get the whole trace.

Pay attention to the particular line where it stops, if it stops at all.

@mcornella

This comment has been minimized.

Collaborator

mcornella commented Oct 10, 2016

@SebTM the asciinema video doesn't capture terminal pauses... You can try disabling plugins one by one and checking the load time with your custom command.

@nicohvi

This comment has been minimized.

nicohvi commented Oct 10, 2016

Sure thing @mcornella 👍

@NauxChen

This comment has been minimized.

NauxChen commented Nov 1, 2016

zsh -xv > ~/info 2>&1
@austenLacy

This comment has been minimized.

austenLacy commented Nov 3, 2016

@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.

@chefjuanpi

This comment has been minimized.

chefjuanpi commented Nov 3, 2016

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

@przbadu

This comment has been minimized.

przbadu commented Nov 25, 2016

@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

@gerardbm

This comment has been minimized.

gerardbm commented Nov 30, 2016

I had the same problem in my terminal. As a GNU/Linux user, I removed these two lines from the file .zprofile:

export NVM_DIR=~/.nvm
source ~/.nvm/nvm.sh

I needed them to use jshint on Sublime Text. Recently I switched to Neovim, so I can remove them.

Now the load time is about 2 seconds.

@9mm

This comment has been minimized.

9mm commented Dec 15, 2016

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

creationix/nvm#539 (comment)

@lu4

This comment has been minimized.

lu4 commented Jan 25, 2017

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

@sprig

This comment has been minimized.

sprig commented Jan 26, 2017

I used a profiling function and found out that 'spectrum.zsh' was taking (in the profiler, which runs slower - but still) several seconds. I replaced it temporarily with an empty file and the startup got much faster (still too slow - IMHO it shouldn't take over half a second - but at least bearable).

@9mm

This comment has been minimized.

9mm commented Jan 26, 2017

@sprig

This comment has been minimized.

sprig commented Jan 26, 2017

I don't know. It doesn't seem essential (read the code). it's in $oh-my/lib/spectrum.zsh

@RWOverdijk

This comment has been minimized.

RWOverdijk commented Mar 3, 2017

Slow here as well. I found most of it to be caused by nvm, too.

@T0mK0

This comment has been minimized.

Contributor

T0mK0 commented Mar 15, 2017

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)
@steinybot

This comment has been minimized.

steinybot commented May 1, 2017

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.

@AndrewStobie

This comment has been minimized.

AndrewStobie commented May 8, 2017

I am having a similar problem and have tried most of if not all of these solutions here. I can't even get nvm to run because it was bloating up everything but still even a cd command takes about 2-3 seconds to perform. Does anyone have any tips or is there anything I could post. Sorry I am new to all these. I had a set up on my old computer that worked and I don't know why this one doesn't.

@NikKovIos

This comment has been minimized.

NikKovIos commented May 9, 2017

For me helped... only rebooting my Mac mini. Lol =)

@T0mK0

This comment has been minimized.

Contributor

T0mK0 commented May 11, 2017

#6080 for the chruby & aws plugin users

@johntdyer

This comment has been minimized.

johntdyer commented May 17, 2017

Same here on OSX 10.12.5

Plugins

plugins=(git-extras golang go brew zsh-syntax-highlighting zsh-iterm-touchbar)

Profiles Start

Last login: Wed May 17 07:50:53 on ttys011
num  calls                time                       self            name
-----------------------------------------------------------------------------------
 1)    1         302.63   302.63   52.34%    302.63   302.63   52.34%  compdump
 2)    1         536.02   536.02   92.70%    111.98   111.98   19.37%  compinit
 3)  638          93.05     0.15   16.09%     93.05     0.15   16.09%  compdef
 4)    2          29.60    14.80    5.12%     29.60    14.80    5.12%  compaudit
 5)    2          20.22    10.11    3.50%     20.22    10.11    3.50%  grep-flag-available
 6)    2          17.83     8.92    3.08%     17.83     8.92    3.08%  env_default
 7)    2           2.39     1.20    0.41%      2.39     1.20    0.41%  colors
 8)    1           0.35     0.35    0.06%      0.35     0.35    0.06%  is-at-least
 9)    2           0.08     0.04    0.01%      0.08     0.04    0.01%  is_plugin
10)    1           0.08     0.08    0.01%      0.07     0.07    0.01%  iterm2_print_state_data
11)    1           0.01     0.01    0.00%      0.01     0.01    0.00%  iterm2_print_user_vars

-----------------------------------------------------------------------------------

 2)    1         536.02   536.02   92.70%    111.98   111.98   19.37%  compinit
       1/2        29.60    29.60    5.12%      0.52     0.52             compaudit [4]
     622/638      91.81     0.15   15.88%     91.81     0.15             compdef [3]
       1/1       302.63   302.63   52.34%    302.63   302.63             compdump [1]

-----------------------------------------------------------------------------------

       1/1       302.63   302.63   52.34%    302.63   302.63             compinit [2]
 1)    1         302.63   302.63   52.34%    302.63   302.63   52.34%  compdump

-----------------------------------------------------------------------------------

     622/638      91.81     0.15   15.88%     91.81     0.15             compinit [2]
 3)  638          93.05     0.15   16.09%     93.05     0.15   16.09%  compdef

-----------------------------------------------------------------------------------

       1/2        29.60    29.60    5.12%      0.52     0.52             compinit [2]
       1/2        29.08    29.08    5.03%     29.08    29.08             compaudit [4]
 4)    2          29.60    14.80    5.12%     29.60    14.80    5.12%  compaudit
       1/2        29.08    29.08    5.03%     29.08    29.08             compaudit [4]

-----------------------------------------------------------------------------------

 5)    2          20.22    10.11    3.50%     20.22    10.11    3.50%  grep-flag-available

-----------------------------------------------------------------------------------

 6)    2          17.83     8.92    3.08%     17.83     8.92    3.08%  env_default

-----------------------------------------------------------------------------------

 7)    2           2.39     1.20    0.41%      2.39     1.20    0.41%  colors

-----------------------------------------------------------------------------------

 8)    1           0.35     0.35    0.06%      0.35     0.35    0.06%  is-at-least

-----------------------------------------------------------------------------------

 9)    2           0.08     0.04    0.01%      0.08     0.04    0.01%  is_plugin

-----------------------------------------------------------------------------------

10)    1           0.08     0.08    0.01%      0.07     0.07    0.01%  iterm2_print_state_data
       1/1         0.01     0.01    0.00%      0.01     0.01             iterm2_print_user_vars [11]

-----------------------------------------------------------------------------------

       1/1         0.01     0.01    0.00%      0.01     0.01             iterm2_print_state_data [10]
11)    1           0.01     0.01    0.00%      0.01     0.01    0.00%  iterm2_print_user_vars

@johntdyer

This comment has been minimized.

johntdyer commented May 17, 2017

So I did just try updating ZSH and it appears things got a little better...

zsh 5.3.1 (x86_64-apple-darwin16.3.0)

Last login: Wed May 17 07:56:11 on ttys012
num  calls                time                       self            name
-----------------------------------------------------------------------------------
 1)    1          61.67    61.67   53.21%     42.56    42.56   36.73%  compinit
 2)    2          26.71    13.36   23.05%     26.71    13.36   23.05%  grep-flag-available
 3)    2          24.06    12.03   20.77%     24.06    12.03   20.77%  env_default
 4)    2          19.11     9.55   16.49%     19.11     9.55   16.49%  compaudit
 5)    2           2.49     1.24    2.14%      2.49     1.24    2.14%  colors
 6)   11           0.34     0.03    0.30%      0.34     0.03    0.30%  is_plugin
 7)    1           0.30     0.30    0.26%      0.30     0.30    0.26%  is-at-least
 8)    2           0.23     0.11    0.19%      0.23     0.11    0.19%  compdef
 9)    1           0.09     0.09    0.08%      0.08     0.08    0.07%  iterm2_print_state_data
10)    1           0.01     0.01    0.01%      0.01     0.01    0.01%  iterm2_print_user_vars

-----------------------------------------------------------------------------------

 1)    1          61.67    61.67   53.21%     42.56    42.56   36.73%  compinit
       1/2        19.11    19.11   16.49%      0.39     0.39             compaudit [4]

-----------------------------------------------------------------------------------

 2)    2          26.71    13.36   23.05%     26.71    13.36   23.05%  grep-flag-available

-----------------------------------------------------------------------------------

 3)    2          24.06    12.03   20.77%     24.06    12.03   20.77%  env_default

-----------------------------------------------------------------------------------

       1/2        19.11    19.11   16.49%      0.39     0.39             compinit [1]
       1/2        18.71    18.71   16.15%     18.71    18.71             compaudit [4]
 4)    2          19.11     9.55   16.49%     19.11     9.55   16.49%  compaudit
       1/2        18.71    18.71   16.15%     18.71    18.71             compaudit [4]

-----------------------------------------------------------------------------------

 5)    2           2.49     1.24    2.14%      2.49     1.24    2.14%  colors

-----------------------------------------------------------------------------------

 6)   11           0.34     0.03    0.30%      0.34     0.03    0.30%  is_plugin

-----------------------------------------------------------------------------------

 7)    1           0.30     0.30    0.26%      0.30     0.30    0.26%  is-at-least

-----------------------------------------------------------------------------------

 8)    2           0.23     0.11    0.19%      0.23     0.11    0.19%  compdef

-----------------------------------------------------------------------------------

 9)    1           0.09     0.09    0.08%      0.08     0.08    0.07%  iterm2_print_state_data
       1/1         0.01     0.01    0.01%      0.01     0.01             iterm2_print_user_vars [10]

-----------------------------------------------------------------------------------

       1/1         0.01     0.01    0.01%      0.01     0.01             iterm2_print_state_data [9]
10)    1           0.01     0.01    0.01%      0.01     0.01    0.01%  iterm2_print_user_vars
@davidawad

This comment has been minimized.

davidawad commented May 29, 2017

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/

@tabair-addepar

This comment has been minimized.

tabair-addepar commented Jun 8, 2017

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

@shuiqingliu

This comment has been minimized.

shuiqingliu commented Jun 10, 2017

Thanks @tabair-addepar ,I found the very slowly point is the plugin named command-not-found by user your debug method.I remove this plugin and the problem have been solved.

@sitano

This comment has been minimized.

sitano commented Sep 5, 2017

I have a huge issue with ZSH and iTerm2 on MacOS 10.12.6 (latest MacBook Pro).

When I type anything in the shell, I see opendirector consumes up to 50% of the CPU, the whole system slows down... and automountd consumes up to 15%.

There is an advice on net about cleaning up the DropBox broken links, but thats a nonsense and I have no broken links in DropBox; and for whatever reason, why should I care about the links...

Yet, Bash works fine. But the vim works the same bad.

for zsh it happens due to the something in /usr/local/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh but do not have an idea whats in there could be causing this.

@sitano

This comment has been minimized.

sitano commented Sep 6, 2017

This solved my issue: https://apple.stackexchange.com/questions/33312/opendirectoryd-taking-up-1-4-of-the-cpu-and-driving-fans-crazy-on-macbook-air

As mentioned by @marek / @juanpablo, this may be caused by symlinks.

Apparently, if a symlink points to /home, autofs or automountd fire and take a lot of CPU to figure out that the place indeed doesn't exist.

Take a look at /etc/auto_home and /etc/autofs.conf.

To see if you're being hit by this particular problem, set

AUTOMOUNTD_VERBOSE=TRUE
option in autofs.conf, restart automountd

sudo launchctl stop com.apple.automountd
and review the syslog.log (you may use application: Console). You're affected by this problem if you see something like that:

May 20 17:53:43 xxx automountd[31709]: od_search failed
To workaround, edit the file /etc/auto_master and remove (or hash out #) the line starting with /home. Then run:

sudo automount -vc

@robbyrussell

This comment has been minimized.

Owner

robbyrussell commented Nov 1, 2017

I appreciate all the help everyone is providing for these edge cases/debugging approaches. I'm going to close this issue but hope folks can find this useful

@greggman

This comment has been minimized.

greggman commented Nov 19, 2017

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.

@zongwu233

This comment has been minimized.

zongwu233 commented Jan 4, 2018

Thanks to @tabair-addepar
I find 'curl --silent --location --connect-timeout 7 --max-time 10 https://api.sdkman.io/2/candidates/all ' wait for 7 second in the debug log.
I reduce timeout config ,That OK.
And another one is

0.000015 +prompt_end:1> [[ -n blue ]]
0.000009 +prompt_end:2> echo -n ' %{%k%F{blue}%}⮀'
0.000010 +prompt_end:6> echo -n '%{%f%}'
0.000009 +prompt_end:7> CURRENT_BG=''
3.963591 ^[[?1h^[=+_main_complete:11> local 'IFS=
0.000091 ^@'
@eromoe

This comment has been minimized.

eromoe commented Jan 11, 2018

This line is super slow in my windows 7 msys2 env

+git_prompt_info:2> [[+git_prompt_info:2> git config --get oh-my-zsh.hide-status

But I have already disable git

plugins=(
  #git
  zsh-autosuggestions
)

What should I do ?

@eromoe

This comment has been minimized.

eromoe commented Jan 11, 2018

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() {}
@revolter

This comment has been minimized.

Contributor

revolter commented Feb 10, 2018

If I have

0.000022 +prompt_char:16> echo -n '%(!.%F{red}#.%F{green}>%f)'
38.914652 �[?1h�=�[?1l�>nvim zsh_startup.log

does this mean that echo took 0.38 seconds?

@tabair-addepar

This comment has been minimized.

tabair-addepar commented Feb 12, 2018

@revolter Umm... I think that means echo took almost 39 seconds. Which is very odd. Can you show us the command you entered to generate your startup log? If we're lucky, there's just something odd about how you generated the log. If not, that's kind of a head scratcher.

@revolter

This comment has been minimized.

Contributor

revolter commented Feb 12, 2018

@tabair-addepar, I just ran zsh -xv 2>&1 | ts -i "%.s" > zsh_startup.log from your comment.

I now get:

0.000037 +prompt_char:16> echo -n '%(!.%F{red}#.%F{green}>%f)'
5.827991 �[?1h�=�[?1l�>nvim zsh_startup.log
...
0.000027 +prompt_char:16> echo -n '%(!.%F{red}#.%F{green}>%f)'
3.305347 �[?1h�=�[?1l�>nvim zsh_startup.log
@tabair-addepar

This comment has been minimized.

tabair-addepar commented Feb 14, 2018

Well, I think we're both doubtful that echo is actually taking that long to execute. That "+prompt_char:16" means that you're one subshell deep, and, I think, inside a function or script named "prompt_char". That's probably the function that sets your command prompt or maybe it's even as simple as a function that's deciding what the last character of your prompt should be based on what your UID is.

If that function had some logic in it that was responsible for the delay, that would show up in this log as the offending line instead of this echo. Since I see what appears to be a prompt getting printed on the "nvim" line, that delay could be caused by your prompt_cmd that runs before each prompt is printed. Maybe prompt_cmd isn't being caught in the log for some reason?

Can I see a full log? Perhaps there's more telling info in there somewhere.

@wzrdtales

This comment has been minimized.

wzrdtales commented Mar 12, 2018

For the nvm issues, I had the same, just entered what I am using all the time as a plugin #6671

@redhackthings

This comment has been minimized.

redhackthings commented Apr 28, 2018

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

@jesstelford

This comment has been minimized.

jesstelford commented May 4, 2018

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') 🎉

@eightygrit

This comment has been minimized.

eightygrit commented May 7, 2018

The script referenced directly above made the biggest difference for me. After trying everything else in this thread, I still had a 6.9 second load time because I was loading the zsh plugins that depended on nvm, so loading of nvm wasn't really delayed.

Adding this script and removing the relevant zsh plugins reduced the time from 6.9 seconds to 1.2 seconds.

And as you might expect, executing npm or one of the other commands for the first time takes a little longer, but that's a perfectly acceptable trade-off.

@wzrdtales

This comment has been minimized.

wzrdtales commented May 7, 2018

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:

wzrdtales/nvm-ng#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 #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.

@partounian

This comment has been minimized.

Contributor

partounian commented Aug 29, 2018

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

@addozhang

This comment has been minimized.

addozhang commented Sep 29, 2018

I disable the oc, kubectl, docker plugin and comment the initialization of nvm and sdkman.

Additionally, switch command of Default profile from Login shell to Command with /usr/bin/login -pfq xxx filled. xxx is your username.

It runs fast now.

@yalok

This comment has been minimized.

yalok commented Oct 25, 2018

My zsh was starting about 10 seconds. After manual upgrade_oh_my_zsh it now flies !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment