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

startup bash too slow with nvm loading in .bashrc config #776

Closed
mzvast opened this Issue Aug 5, 2016 · 36 comments

Comments

Projects
None yet
@mzvast
Copy link

mzvast commented Aug 5, 2016

Describe

It is too slow to startup a new bash shell, 10sec or so, with following 2 lines at the bottom of .bashrc:

export NVM_DIR="/home/mzvast/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm

In TMUX, it is extremely terrible to split a window and wait for a new bash to init.

It seems that every new bash needs to be inited with same amount of time,no matter whether there has bash instances been running in background.

Reproduce steps

  1. run curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.31.4/install.sh | bash
  2. reopen bash, it gets slow on init immediately

OS version,etc.

system:14393 win10 pro x64
hardware: Intel i5 2.5GHz, 6GB RAM, 256GB SSD

@adouzzy

This comment has been minimized.

Copy link

adouzzy commented Aug 5, 2016

probably you should exam your .bashrc
For initializing fasd would cause slow startup

@iz0eyj

This comment has been minimized.

Copy link

iz0eyj commented Aug 5, 2016

No lag on my Core I7 & SSD Samsung 850 pro, startup time is near 0 sec.

Strange thing, some second to wait using the "sudo" command.

@mzvast

This comment has been minimized.

Copy link
Author

mzvast commented Aug 5, 2016

@adouzzy You are right, after commenting out following lines,which loads nvm ,it starts fine again.

#export NVM_DIR="/home/mzvast/.nvm"
#[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm

I think this may be a performance issue with bash on windows, because the same bash config startup very fast in my vps.

@mzvast mzvast changed the title startup bash too slow startup bash too slow with some bashrc config Aug 5, 2016

@benhillis

This comment has been minimized.

Copy link
Member

benhillis commented Aug 5, 2016

I've also noticed nvm slowing down bash launch. It would be very helpful if we could narrow down what is causing the delay via an strace.

@mzvast mzvast changed the title startup bash too slow with some bashrc config startup bash too slow with nvm koads in .bashrc config Aug 6, 2016

@mzvast mzvast changed the title startup bash too slow with nvm koads in .bashrc config startup bash too slow with nvm loads in .bashrc config Aug 6, 2016

@mzvast mzvast changed the title startup bash too slow with nvm loads in .bashrc config startup bash too slow with nvm loading in .bashrc config Aug 6, 2016

@arcanis

This comment has been minimized.

Copy link

arcanis commented Aug 6, 2016

This can be partially solved by using --no-use, but the real culprit definitely is nvm use and, to a lower extend, nvm version.

@rcdosado

This comment has been minimized.

Copy link

rcdosado commented Nov 2, 2016

after commenting the command below in .bashrc, i have removed a 4 second+ delay to the loading of the terminal, any idea how to make this faster at least?thanks, using ubuntu 16 :

export NVM_DIR="/home/username/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm

@davatron5000

This comment has been minimized.

Copy link

davatron5000 commented Dec 9, 2016

Confirming. It's adding ~30s to shell startup on my machine. (Core i7 6500k w/ M.2 SSD)

me@computer:~$ time (source "$NVM_DIR/nvm.sh")

real    0m29.657s
user    0m1.484s
sys     0m32.141s

Edit: Workaround. Use n instead. https://github.com/tj/n

me@computer:~$ time (source ~/.bashrc)

real    0m1.806s
user    0m0.156s
sys     0m1.594s
@reybango

This comment has been minimized.

Copy link

reybango commented Mar 22, 2017

Confirming that this is still an issue in the latest Selfhost.

@sunilmut

This comment has been minimized.

Copy link
Member

sunilmut commented Mar 23, 2017

Thanks for the report @reybango.

If someone can collect an strace with relative timestamp and share them out, then it will be easy to see where the delay is coming from.

strace -t -o ‘trace_file’ -ff $NVM_DIR/nvm.sh

And, share out the trace files.

@arcanis

This comment has been minimized.

Copy link

arcanis commented Mar 23, 2017

Here are my trace files:

trace.tar.gz

@bmayen

This comment has been minimized.

Copy link

bmayen commented Mar 23, 2017

I get "strace: exec: Exec format error" when running that :/

@asclines

This comment has been minimized.

Copy link

asclines commented Mar 23, 2017

I would like to say that I (like @bmayen ) get strace: exec: Exec format error when running strace

@reybango

This comment has been minimized.

Copy link

reybango commented Mar 23, 2017

@sunilmut could you give more precise instructions on running the strace?

@arcanis

This comment has been minimized.

Copy link

arcanis commented Mar 23, 2017

I believe the right command is strace -t -o ‘trace_file’ -ff bash $NVM_DIR/nvm.sh, otherwise you're asking strace to exec a shell script, which won't work.

@asclines

This comment has been minimized.

Copy link

asclines commented Mar 23, 2017

Upon running the strace command the way @arcanis suggested, several trace_files (215) were created. Is this an expected result? If so, what exactly is @sunilmut expecting from this?

@arcanis

This comment has been minimized.

Copy link

arcanis commented Mar 23, 2017

Being a bash script, nvm is executing various command in various processes. Strace is logging each of these processes in a separate file. Since I'm not sure which is the best way to sort them without losing info, I just tarball'd them :|

@sunilmut

This comment has been minimized.

Copy link
Member

sunilmut commented Mar 23, 2017

@arcanis - Thanks for sharing the traces. The idea is to see which command is taking long to execute. Since the trace file has the timestamps, it would hopefully make it easier to gather that information. I haven't gone through the traces yet, but it's available here for anyone to parse and see.

@stehufntdev

This comment has been minimized.

Copy link
Collaborator

stehufntdev commented Apr 6, 2017

We tracked down the slow nvm start-up time using xperf, and it’s a known perf bottle neck in clone\fork when copying address space information. We were already planning on the fix so it should be out to insider builds soon.

@mrmckeb

This comment has been minimized.

Copy link

mrmckeb commented Apr 26, 2017

@stehufntdev Will releases coincide with Windows releases? Or is there a chance of a mid-cycle update? As this is still technically a pre-release, it would be cool to see features added to the WSL more regularly - installing the Insider builds of Windows can obviously have other effects...

@stehufntdev

This comment has been minimized.

Copy link
Collaborator

stehufntdev commented Apr 26, 2017

@mrmckeb thanks for the feedback. Pushing out changes to the Creator's update is currently gated through servicing criteria which has a pretty high bar and requires data on the impact. We would like to get to the point were mid-cycle updates can go out, but unfortunately aren't there yet. This change will likely fall into the other category where it is flighted to insider builds and available in the next official release of Windows.

@stehufntdev

This comment has been minimized.

Copy link
Collaborator

stehufntdev commented Apr 28, 2017

A fix for this should be out for insider builds soon that reduces nvm start-up by ~60%. On my test vm it took the launch from 12 seconds to 5 seconds. @benhillis reminded me that percentages are hard, and it sounds much better if we say it's ~2.5x!!! faster :).

We understand where the remaining time is being spent and are tracking additional work to bring this down closer to native Linux speeds.

@reybango

This comment has been minimized.

Copy link

reybango commented Apr 28, 2017

@stehufntdev note that I had seen better perf in 16179 than in 16184. Went from maybe 5-10 seconds max to nearly 2 minutes now. I commented the loading of nvm in .zshrc with no improvement. Then I commented loading the zsh shell (oh my zsh) altogether and the normal bash shell loads near instantaneous.

Now the one behavior I'm seeing while loading the zsh shell is that during the long length of time, if I break out using CTRL-C, the zsh shell is loaded. Maybe this is some type of hang or race condition?

@stehufntdev

This comment has been minimized.

Copy link
Collaborator

stehufntdev commented Apr 28, 2017

@reybango, thanks for the update. Can you start a new thread on the zsh issue so we can take a look?

@DaniGithub

This comment has been minimized.

Copy link

DaniGithub commented May 10, 2017

My bash on windows is also having this issue. It takes about 12s to start without commenting out the second line from the code below. If i do comment it out, then the start time is almost instant.

`export NVM_DIR="$HOME/.nvm"

#[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm

[ -s "$NVM_DIR/bash_completion" ] && . "$NVM_DIR/bash_completion" # This loads nvm bash_completion`

@matteing

This comment has been minimized.

Copy link

matteing commented May 18, 2017

Same issue here.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

therealkenc commented Jun 9, 2017

NVM's bash_completion seems qualitatively better in 16215.

@stehufntdev

This comment has been minimized.

Copy link
Collaborator

stehufntdev commented Jun 9, 2017

Great to hear. I'm going to close this out as fixed for insiders and we can take a look if anything new comes up.

@stehufntdev stehufntdev closed this Jun 9, 2017

@djensen47

This comment has been minimized.

Copy link

djensen47 commented Jul 23, 2017

I'm using 16241 and it's still unacceptably slow. 😕

@EdwinHu233

This comment has been minimized.

Copy link

EdwinHu233 commented Sep 8, 2017

The nvm path slowed down my bash (and zsh) on my Ubuntu 16.04, too. After removing it from .bashrc (or .zshrc) it's much better.

@dreamzzzz

This comment has been minimized.

Copy link

dreamzzzz commented Sep 26, 2017

Problem solved fix don't use nvm =)
Thanks

@alberduris

This comment has been minimized.

Copy link

alberduris commented Feb 14, 2018

This is still an issue.

@peey

This comment has been minimized.

Copy link

peey commented Feb 27, 2018

Related Thread: creationix/nvm#782

If you installed node without nvm (the system installation), and that is what you usually use, and you use nvm for only switching to other versions of node, then this comment on that thread is a nice workaround

@well1791

This comment has been minimized.

Copy link

well1791 commented Oct 19, 2018

@jcklpe

This comment has been minimized.

Copy link

jcklpe commented Nov 24, 2018

Still having this problem. Wicked slow.

@jcklpe

This comment has been minimized.

Copy link

jcklpe commented Nov 24, 2018

Thanks for the snippet @well1791 it didn't speed stuff up much but it did stop stuff from constantly telling me that nvm wasn't installed when it was.

@KenG98

This comment has been minimized.

Copy link

KenG98 commented Dec 11, 2018

I'm also experiencing this. Quick fix for people who don't use nvm too often - in your bashrc put the nvm related lines into a function and call the function when you need to use nvm. This way it doesn't slow bash down while starting, you only need to wait right before you use it for the first time.

Gist: https://gist.github.com/KenG98/2d084a9859637cdd1614ba27485e2ef9

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