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

NVM getting very slow on startup in Bash #1277

Open
ahennie opened this Issue Oct 29, 2016 · 112 comments

Comments

Projects
None yet
@ahennie

ahennie commented Oct 29, 2016

I love NVM, but I've noticed that NVM is getting really slow during startup. See attached screenshot for what I mean: http://take.ms/LPOv3

Is this a bug or is something wrong on my Mac?

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Oct 29, 2016

What's nvm ls and nvm debug print out?

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Oct 29, 2016

You can also try adding --no-use to the end of the second nvm line (the one doing the sourcing) to confirm that it's the auto-use code path that's being slow.

@ahennie

This comment has been minimized.

ahennie commented Oct 31, 2016

@ljharb
Adding --no-use makes it superfast, but then it doesnt load node. But I guess it confirms that the auto-use code path is slow. Here are the nvm ls and nvm debug

nvm ls
->       v6.9.1
default -> 6.9.1 (-> v6.9.1)
node -> stable (-> v6.9.1) (default)
stable -> 6.9 (-> v6.9.1) (default)
iojs -> N/A (default)
lts/* -> lts/boron (-> v6.9.1)
lts/argon -> v4.6.1 (-> N/A)
lts/boron -> v6.9.1
nvm debug
nvm --version: v0.32.1
$SHELL: /bin/bash
$HOME: /Users/Andreas
$NVM_DIR: '$HOME/.nvm'
$PREFIX: ''
$NPM_CONFIG_PREFIX: ''
nvm current: v6.9.1
which node: $NVM_DIR/versions/node/v6.9.1/bin/node
which iojs:
which npm: $NVM_DIR/versions/node/v6.9.1/bin/npm
npm config get prefix: $NVM_DIR/versions/node/v6.9.1
npm root -g: $NVM_DIR/versions/node/v6.9.1/lib/node_modules
@ljharb

This comment has been minimized.

Collaborator

ljharb commented Oct 31, 2016

Do you have a .nvmrc file anywhere, like ~/.nvmrc?

@ahennie

This comment has been minimized.

ahennie commented Oct 31, 2016

@ljharb the one line I have in that file is
onload-script=npm-autoinit/autoinit

Tried to remove it, didn't make any difference, so added it back.

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Nov 1, 2016

@ahennie in a file called nVmrc, you have that line?

Can you provide a little more info on your Mac? Do you have an SSD, how old is it, how fast/much RAM, etc?

@mitermayer

This comment has been minimized.

mitermayer commented Nov 2, 2016

This is also very slow for me on gentoo linux.

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Nov 2, 2016

@mitermayer can you also go through the same steps above and see if you get the same or different results?

@ahennie

This comment has been minimized.

ahennie commented Nov 3, 2016

@ljharb Sorry, that was .nPmrc. I don't have a .nVmrc-file. It must be sw, not hw related. I got Macbook Pro 15" i7, 16gb RAM, SSD. What could it be?

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Nov 3, 2016

@ahennie that should be fast enough. Basically it's that nvm use calls into npm config get prefix, which is very slow. I'll keep looking into it.

@ahennie

This comment has been minimized.

ahennie commented Nov 4, 2016

@ljharb thanks. it wasnt slow like this earlier. does the number of global modules affect the speed? other things I can do to speed it up?

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Nov 4, 2016

When you say "earlier" do you mean on an earlier version, before I was doing prefix checking? Or do you mean on the same version of nvm?

@carlosjs23

This comment has been minimized.

carlosjs23 commented Nov 5, 2016

same issue too.

@ahennie

This comment has been minimized.

ahennie commented Nov 7, 2016

@ljharb it's hard to say. I installed nvm months ago, but never really used node. However loading the bash has always been fast. I have been coding node a lot more lately, including installing a few global modules, and it suddenly have gotten slower. I also updated to the newest version of nvm, npm and node. Deleted a few global modules now, but it's still slow. So I think the slowness was intruduced in any of the updates.

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Nov 7, 2016

It's likely the npm config get prefix call then.

@ahennie

This comment has been minimized.

ahennie commented Nov 8, 2016

@ljharb suddenly it's faster again. don't know why. but I thought you should know, before you spend to much time on it.

@ryankask

This comment has been minimized.

ryankask commented Nov 10, 2016

I just checked out the latest tag and noticed this. I forget what tag I was previously using but it was in the v0.31 series.

Adding the the --no-use fixes the issue.

@Nick011

This comment has been minimized.

Nick011 commented Nov 23, 2016

Experiencing the same problem. Everything was fine until I upgraded OSX to Sierra a few days ago. Ran brew update and brew upgrade, but it's still slow. --no-use Makes it better, but still slightly slower than what it was before I upgraded.

When I run nvm ls It takes about 2-3 seconds to start, then lists everything down to system then takes 2-3 seconds for every alias after that. Here is my output:

➜  ~ nvm ls
        v5.10.1
         v6.1.0
         v6.6.0
->       v6.9.1
         system
default -> v6.9.1
node -> stable (-> v6.9.1)
stable -> 6.9 (-> v6.9.1) (default)
iojs -> iojs- (-> system) (default)
lts/* -> lts/boron (-> v6.9.1)
lts/argon -> v4.6.2 (-> N/A)
lts/boron -> v6.9.1

I'm running a 2013 15in macbook pro. 2.7Ghz, 16GB RAM.
I'm using iterm2 and oh-my-zsh, but saw someone else here had the same problem with bash.

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Nov 24, 2016

@Nick011 nvm is not supported via homebrew (the homebrew formula says this when you install it). If you brew uninstall nvm, and then install it properly via the curl script in the readme, my suspicion is that it will go much faster.

@nico1510

This comment has been minimized.

nico1510 commented Nov 25, 2016

same issue here... --no-use fixes it but also fails to load node

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Nov 25, 2016

@nico1510 right, the npm config get prefix call that nvm is making when running nvm use is the slowest part. I don't yet have a solution to speed that up.

@martinheidegger

This comment has been minimized.

martinheidegger commented Dec 6, 2016

To investigate the performance issues myself, I tried to setup some performance logging in a forked branch:
https://github.com/martinheidegger/nvm/tree/debug/performance

and I also come to the conclusion that the biggest issue is starting node. (npm config get prefix is a node script, as opposed to all the other scripts).

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Dec 6, 2016

@martinheidegger i think you're spot on. If anyone can come up with a way to perfectly emulate npm config get prefix without invoking node (especially if it can be PRred into npm itself so that they'll keep it up to date), that would likely erase most people's performance issues.

@martinheidegger

This comment has been minimized.

martinheidegger commented Dec 6, 2016

@ljharb I ran another test for the performance of npm config get prefix and it seems to have not changed much over the versions: https://gist.github.com/martinheidegger/32d00e90e0163a22a4ffc78df796001e

I opened npm/npm#15149 added comments to npm/npm#14458 (comment) in order to let the npm team know of this problem as well (with some extended info).

@martinheidegger

This comment has been minimized.

martinheidegger commented Dec 13, 2016

I opened nodejs/help#396 in order to figure out if Node.js and NPM could share the same logic in order for nvm to not need to rely on Node and/or make NPM faster.

Quoting:

If npm wanted to use that, they should file an issue or pull request to make it public API.

I guess same can be said of nvm?

@wzrdtales

This comment was marked as off-topic.

wzrdtales commented May 31, 2018

@ljharb he ment shell startup time, not nvm. he completely avoids nvm here unless he needs it.

@ljharb

This comment was marked as off-topic.

Collaborator

ljharb commented May 31, 2018

@wzrdtales yes, the implication of the comment is that they're concerned about shell startup time with nvm properly enabled - i'm suggesting that the brew-installed node, combined with enabling nvm properly, is the cause of the slowdown, and that if the brew-installed node is removed, no hacks or workarounds for nvm will be needed.

@wzrdtales

This comment was marked as off-topic.

wzrdtales commented May 31, 2018

@ljharb no actually nvm is the reason for the shell slowdown, and the reason for the nvm slodown is npm. if you read his answer closely he never stated anything about nvm, but he removed nvm from his shell startup alltogether and replaced it by a dynamic script. nvm is slow this is a hard fact, that is why I have a long while ago submitted fixes to the issues, but we did not came along well and I ended up dropping the original nvm completely.

Here is a mini bench of just calling nvm from the console. Around half a second is clearly too much. And that is why people are complaining, nothing more. nvm is awesome to what it provides, it just is a bad deal for everyone that actually uses it shell to be productive, like me since i am a neovim user I operate exclusively in the shell.

time zsh nvm.sh          
zsh nvm.sh  0,39s user 0,06s system 114% cpu 0,396 total

Btw. I am still on nvms side, that is why I still watch these issues waiting for the day you finally move in and allow the fixes to be made. I wont help this time since I tried it once though, but I will be more than happy to deprecate my hard fork as soon as this gets fixed :)

@ljharb

This comment was marked as off-topic.

Collaborator

ljharb commented Jun 1, 2018

@wzrdtales many people have already reported that their nvm slowdowns vanish when they uninstall their brew-installed node. I understand that it's the combination causing the issue, but uninstalling a brew-installed node so far has seemed like a viable solution.

@tomchiverton

This comment was marked as off-topic.

tomchiverton commented Jun 1, 2018

@wzrdtales

This comment was marked as off-topic.

wzrdtales commented Jun 1, 2018

@ljharb Might be, just stated in this case, he chose a brew install instead of nvm, I don't think that the node installation was the problem but the solution over nvm. However, I don't have time for this, still hoping you will someday look into the fixes and improvements and change your mind, b/c those are easily fixable, this is just a problem of opinions here, which I am fine with I stated that already in our early conversations, still I disagree strongly. And for me it doesn't matter anyway I have my hard fork which loads in 4ms, so I've got it sorted, but I guess this discussion here will never end though.

@ljharb

This comment was marked as off-topic.

Collaborator

ljharb commented Jun 1, 2018

@wzrdtales a brew install of nvm will always be broken and is totally unsupported - nvm must never be installed from homebrew.

I've already made some improvements and am working on others.

@eloytoro

This comment has been minimized.

eloytoro commented Jun 1, 2018

I have a fresh installation of nvm (no other installation of node) and its about 800ms of startup time on my bash.
Is the workaround above the best solution? Is the nvm team going to endorse this?

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Jun 1, 2018

@eloytoro I'm the nvm team, and I'm not endorsing any workaround except #1277 (comment) (or waiting).

However, I'm actively (albeit slowly) working on addressing this problem, and will be sure to update here as I do.

@marclipovsky

This comment has been minimized.

marclipovsky commented Jun 2, 2018

Small update to @Stanzilla's script. If you're using zsh's chpwd add-zsh-hook to update the node version based on a .nvmrc or .node-version file, use this script:

load-nvmrc() {
  if [[ -f .node-version && -r .node-version ]]; then
    nvm use &> /dev/null
  elif [[ $(nvm version) != $(nvm version default)  ]]; then
    nvm use &> /dev/null
  fi
  setRightPrompt
}

# 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' 'topgun')
  function __init_nvm() {
    for i in "${__node_commands[@]}"; do unalias $i; done
    . "$NVM_DIR"/nvm.sh
    unset __node_commands
    unset -f __init_nvm
    add-zsh-hook chpwd load-nvmrc
    load-nvmrc
  }
  for i in "${__node_commands[@]}"; do alias $i='__init_nvm && '$i; done
fi
@wzrdtales

This comment was marked as off-topic.

wzrdtales commented Jun 2, 2018

@ljharb Since your changes are looking like you would now unlike in the past touch the npm stuff. look at #1597 and #1596 again which fixes the NPM stuff, or better does the easy standardized stuff with other toolings. And this change wzrdtales/nvm-ng@ca95a3f eliminates basically the boot time alltogether, there are some more fixes beyond that for zsh to make some of the array stuff work, that you need to pick up yourself from the commit history though. Feel free to adapt.

Additionally to that, to completely get rid of all the load time, either defer the menu initialization by default, or better just rewrite nvm in a compiled language instead.

@ljharb

This comment was marked as off-topic.

Collaborator

ljharb commented Jun 2, 2018

nvm will never be written in anything but posix, and if it did, it would only ever be in JavaScript, so that’s even not worth bringing up.

Regarding #1596, that’s still open only because the specific technical choice to use npm config get prefix isn’t permanent; however, checking the prefix will never be removed.

#1597 is still open because I’m still hoping you’ll adapt the PR in the way I’ve requested (which includes not removing the npm call).

@wzrdtales

This comment was marked as off-topic.

wzrdtales commented Jun 2, 2018

@ljharb As said, I still disagree and I wont invest anymore time in that PR nor will I open one for the other improvement linked above. I tried it once, and decided for myself it is not worth the hassle and time. Since what you want is keeping npm and not allowing removing it as dependency for checking the prefix stuff, I wont adjust the PR and since it lays around for so long now and my priorities have changed I probably will never.

And you seem to get something wrong here, may be read the whole discussion in both issue and PR again. I never removed the check, I replaced it with equivalents that do the exact same as npm config get prefix and you've been the blocking factor, you even asked me to remove the removal of npm and leave the additional check added which would just make matters worse since that would mean even more loadtime due to another code path.

As said, I just brought that up once more, if you do not want to move forward with my suggestion, this is your absolute freedom, but alternatively you have to come up with something else to make your users happy. B/c for me it doesn't matter I do not use nvm anymore but my hard fork.

TL;DR; As stated above feel free to adapt, this is meant in a friendly way though. However I'm out and I wont support you.

@eloytoro

This comment was marked as off-topic.

eloytoro commented Jun 2, 2018

I'd rather use a fork that fixes this rather than the original, it's quite amazing that this has been around for so long and it's still not being addressed

@vieiralucas

This comment has been minimized.

vieiralucas commented Jun 3, 2018

@eloytoro I'm lazy loading nvm using this.
Might be a good workaround for you 😸

@eloytoro

This comment has been minimized.

eloytoro commented Jun 3, 2018

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Jun 3, 2018

@eloytoro it's already done right - it works correctly. "Slow" is not broken, it's just a subpar experience. Not one person has yet suggested an alternative that actually works correctly with the same level of rigor and robustness, and if one appeared that was equally correct yet faster, I'd happily merge it.

If you're able to write your own per-user per-shell version manager that works correctly in this way for JS (which has different requirements than all the other languages, so those examples are irrelevant) without incurring a performance hit, I'd love to hear about it.

@wzrdtales

This comment was marked as off-topic.

wzrdtales commented Jun 3, 2018

@ljharb Didn't wanted to state anything anymore but

Not one person has yet suggested an alternative that actually works correctly with the same level of rigor and robustness, and if one appeared that was equally correct yet faster, I'd happily merge it.

Sorry I did suggested something that actually works correctly, with the same level of rigor and robustness... .

wzrdtales/nvm-ng#2

Replacing npm with equivalent is robust, since the stuff that was replaced is standardized in npm and will probably never change. It is sad that this went this direction, and it is sad that you feel offended @ljharb just because someone stated that he will do his own version manager. Yes that probably was kinda critique, but this is open source, if someone will do something new b/c one thing doesn't satisfy him he is free to do so. There is no reason to be offended by something like that, that just means these persons are not satisfied, no conculsion arises so they make decisions. That is how things went on, and starting a fight here doesn't make sense, since most here want or wanted to work with you together to fix it.

@ljharb

This comment was marked as off-topic.

Collaborator

ljharb commented Jun 3, 2018

@wzrdtales the comments (#1597 (comment)) I made in #1597 were intended to ask for an iterative approach, and you basically refused to accept that iterative approach - you wanted all or nothing, which is not a very safe way to validate a change, nor one that respects all the existing users.

If replacing with an equivalent is robust, then great! Convince me that's the case and we can move forward - but you've already stated you don't want to "support me" any further, so ¯\_(ツ)_/¯

I'll also note that a slow load time does not "screw up the shell" in any way - it just means you do something else for a short period of time while you wait. As-is, everything works properly, it just works slowly - and more importantly, the slowness is only experienced by a minority of users.

I'm not offended that someone stated they'd make their own version manager, I'm amused, because it's a much harder problem than people realize.

@wzrdtales

This comment was marked as off-topic.

wzrdtales commented Jun 3, 2018

lol ok... I requote myself: I tried it once and I wont waste time anymore here, reason: in this case I don't see any sense in wasting my time with you openly spoken, due to the dialogue we already had. And yes it does screw up your shell, only beause you do not seem to use your shell it does not mean others do not. If you're using neovim + a tiling shell instead of some fancy IDE like atom or stuff, you will notice the pain as hard as it gets. But you do not seem to be a user of (neo)vim or any other powerful shell editor, so you're not affected.

And btw. that was not off topic, but lets keep it fair.

However, I promise you: I will never answer here again, I'm sorry I did, but your last sentence truly disappoints me, I thought you were better than that and still hope you are.

@JBallin

This comment was marked as outdated.

Contributor

JBallin commented Jun 17, 2018

@ljharb I tested removing brew installed node and it still had a slow startup time. I now use the this script, which works really well for me.

@ljharb

This comment was marked as outdated.

Collaborator

ljharb commented Jun 17, 2018

@JBallin thanks for the info, that does help. As for your script, the major caveat is that globally installed modules in your default node version won't be available. What I'd recommend instead of your nvm override is to source nvm.sh with the --no-use option, which will be quite fast, and then you'd run nvm use to activate it when needed.

@JBallin

This comment was marked as resolved.

Contributor

JBallin commented Jun 17, 2018

@ljharb --no-use works great!

@jerroydmoore

This comment has been minimized.

jerroydmoore commented Aug 8, 2018

I've modified the following script to profile nvm: http://www.rosipov.com/blog/profiling-slow-bashrc/ (my modifications add linenumbers: https://gist.github.com/jerroydmoore/3c59107f6c21f29be5691018b5b741b2)

Anyway the worst offender for me (it may vary depending on OS and shell) at > 0.6seconds was nvm_echo on line 840.

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Aug 10, 2018

@jerroydmoore the nvm_echo call itself, which just calls into printf?? or the nvm_alias call inside the subshell call?

@n1kk

This comment has been minimized.

n1kk commented Nov 16, 2018

I'm using nvm with zsh and I've noticed that it is the main source of load delay after recent reinstall of the system.

Adding --no-use makes it faster, but still not as fast as removing it, but since it doesn't load node then whats the point of that anyway.

Here's time load comparison with time zsh -i -c exit:

env incr over prev overall incr output
clean zsh +0 +0 0.00s user 0.00s system 77% cpu 0.011 total
+ oh-my-zsh +0.124 +0.124 0.07s user 0.06s system 94% cpu 0.135 total
+ omz, p9k theme +0.188 +0.312 0.16s user 0.15s system 97% cpu 0.323 total
+ omz, p9k, nvm --no-use +0.827 +1.139 0.50s user 0.37s system 75% cpu 1.151 total
+ omz, p9k, nvm +2.091 +2.403 1.10s user 1.24s system 96% cpu 2.414 total

That's quite a considerable increase for just nvm.

Here is the nvm related output of zsh profiler output (zmodload zsh/zprof)

num  calls                time                       self            name
-----------------------------------------------------------------------------------
 1)    1        1471.81  1471.81   64.66%    586.71   586.71   25.78%  nvm_auto
 2)    1         534.72   534.72   23.49%    534.62   534.62   23.49%  nvm_die_on_prefix
 3)    2         491.21   245.60   21.58%    221.94   110.97    9.75%  compinit
 4)    2         885.10   442.55   38.89%    202.11   101.06    8.88%  nvm
 5)   21         153.88     7.33    6.76%    151.77     7.23    6.67%  p9k::register_segment
 6)    1         142.41   142.41    6.26%    142.41   142.41    6.26%  compdump
 7)    1         142.33   142.33    6.25%    130.89   130.89    5.75%  nvm_ensure_version_installed
 8)  671         105.09     0.16    4.62%    105.09     0.16    4.62%  compdef
 9)    1         221.99   221.99    9.75%     57.65    57.65    2.53%  __p9k_load_segments
10)    5          49.20     9.84    2.16%     49.20     9.84    2.16%  compaudit
11)    1          14.64    14.64    0.64%     14.64    14.64    0.64%  __p9k_update_environment_vars
12)    1          14.14    14.14    0.62%     14.14    14.14    0.62%  nvm_supports_source_options
13)    1          11.45    11.45    0.50%     11.45    11.45    0.50%  nvm_is_version_installed
14)    1           8.47     8.47    0.37%      8.44     8.44    0.37%  __p9k_vcs_init
15)    1           8.00     8.00    0.35%      8.00     8.00    0.35%  __p9k_detect_os
16)    2           7.48     3.74    0.33%      7.48     3.74    0.33%  grep-flag-available
17)    2           6.36     3.18    0.28%      6.36     3.18    0.28%  env_default
18)    3           6.13     2.04    0.27%      6.13     2.04    0.27%  nvm_has
19)    1           7.13     7.13    0.31%      2.95     2.95    0.13%  prompt_powerlevel9k_setup
20)    1           2.92     2.92    0.13%      2.92     2.92    0.13%  __p9k_term_colors
21)    2           2.68     1.34    0.12%      2.68     1.34    0.12%  colors
22)   47           2.91     0.06    0.13%      2.58     0.05    0.11%  p9k::register_icon
23)   34           1.37     0.04    0.06%      1.21     0.04    0.05%  p9k::set_default
24)  198           1.13     0.01    0.05%      1.13     0.01    0.05%  p9k::defined
25)    1           1.12     1.12    0.05%      1.12     1.12    0.05%  is-at-least
26)    4           0.94     0.23    0.04%      0.94     0.23    0.04%  add-zsh-hook
27)    1           0.87     0.87    0.04%      0.76     0.76    0.03%  __p9k_print_deprecation_var_warning
28)    6           0.22     0.04    0.01%      0.22     0.04    0.01%  is_plugin
29)    1           0.21     0.21    0.01%      0.21     0.21    0.01%  __p9k_source_autoloads
30)    1           0.22     0.22    0.01%      0.11     0.11    0.00%  complete
31)    1        1486.03  1486.03   65.29%      0.08     0.08    0.00%  nvm_process_parameters
32)    1           0.08     0.08    0.00%      0.08     0.08    0.00%  __p9k_detect_terminal
33)    1           0.08     0.08    0.00%      0.05     0.05    0.00%  __p9k_print_deprecation_warning
34)    1           0.04     0.04    0.00%      0.04     0.04    0.00%  bashcompinit
35)    1           0.03     0.03    0.00%      0.03     0.03    0.00%  source_env
36)    1           0.02     0.02    0.00%      0.02     0.02    0.00%  p9k::segment_in_use

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

31)    1        1461.05  1461.05   68.37%      0.07     0.07    0.00%  nvm_process_parameters
       1/1        11.95    11.95    0.56%     11.95    11.95             nvm_supports_source_options [13]
       1/1      1449.03  1449.03   67.81%    576.77   576.77             nvm_auto [1]

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

       1/1      1449.03  1449.03   67.81%    576.77   576.77             nvm_process_parameters [31]
 1)    1        1449.03  1449.03   67.81%    576.77   576.77   26.99%  nvm_auto
       1/2       872.27   872.27   40.82%      7.88     7.88             nvm [3]

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

       1/2       872.27   872.27   40.82%      7.88     7.88             nvm_auto [1]
       1/2       864.39   864.39   40.45%    192.03   192.03             nvm [3]
 3)    2         872.27   436.13   40.82%    199.91    99.95    9.35%  nvm
       1/3         5.67     5.67    0.27%      5.67     5.67             nvm_has [18]
       1/1       148.00   148.00    6.93%    135.05   135.05             nvm_ensure_version_installed [6]
       1/1       518.69   518.69   24.27%    518.58   518.58             nvm_die_on_prefix [2]
       1/2       864.39   864.39   40.45%    192.03   192.03             nvm [3]

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

       1/1       518.69   518.69   24.27%    518.58   518.58             nvm [3]
 2)    1         518.69   518.69   24.27%    518.58   518.58   24.27%  nvm_die_on_prefix
       1/3         0.11     0.11    0.01%      0.11     0.11             nvm_has [18]

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

       1/1       148.00   148.00    6.93%    135.05   135.05             nvm [3]
 6)    1         148.00   148.00    6.93%    135.05   135.05    6.32%  nvm_ensure_version_installed
       1/1        12.95    12.95    0.61%     12.95    12.95             nvm_is_version_installed [12]

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

       1/1        12.95    12.95    0.61%     12.95    12.95             nvm_ensure_version_installed [6]
12)    1          12.95    12.95    0.61%     12.95    12.95    0.61%  nvm_is_version_installed

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

       1/1        11.95    11.95    0.56%     11.95    11.95             nvm_process_parameters [31]
13)    1          11.95    11.95    0.56%     11.95    11.95    0.56%  nvm_supports_source_options

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

       1/3         5.67     5.67    0.27%      5.67     5.67             nvm [3]
       1/3         0.11     0.11    0.01%      0.11     0.11             nvm_die_on_prefix [2]
18)    3           5.88     1.96    0.28%      5.88     1.96    0.28%  nvm_has

Here are nvm ls and 'debug' outputs:

$ nvm ls
         v4.0.0
         v8.0.0
       v10.12.0
->      v11.1.0
default -> stable (-> v11.1.0)
node -> stable (-> v11.1.0) (default)
stable -> 11.1 (-> v11.1.0) (default)
iojs -> N/A (default)
lts/* -> lts/dubnium (-> N/A)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.14.4 (-> N/A)
lts/carbon -> v8.12.0 (-> N/A)
lts/dubnium -> v10.13.0 (-> N/A)

$ nvm debug
nvm --version: v0.33.11
$TERM_PROGRAM: iTerm.app
$SHELL: /bin/zsh
$SHLVL: 1
$HOME: /Users/n1kk
$NVM_DIR: '$HOME/.nvm'
$PATH: $NVM_DIR/versions/node/v11.1.0/bin:$HOME/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$HOME/dev/_sdk/haxe_4.0.0_rc5
$PREFIX: ''
$NPM_CONFIG_PREFIX: ''
$NVM_NODEJS_ORG_MIRROR: ''
$NVM_IOJS_ORG_MIRROR: ''
shell version: 'zsh 5.3 (x86_64-apple-darwin18.0)'
uname -a: 'Darwin 18.2.0 Darwin Kernel Version 18.2.0: Fri Oct 5 19:41:49 PDT 2018; root:xnu-4903.221.2~2/RELEASE_X86_64 x86_64'
OS version: Mac 10.14.1 18B75
curl: /usr/bin/curl, curl 7.54.0 (x86_64-apple-darwin18.0) libcurl/7.54.0 LibreSSL/2.6.4 zlib/1.2.11 nghttp2/1.24.1
wget: not found
git: /usr/bin/git, git version 2.17.2 (Apple Git-113)
grep: grep: aliased to grep  --color=auto --exclude-dir={.bzr,CVS,.git,.hg,.svn} (grep --color=auto --exclude-dir={.bzr,CVS,.git,.hg,.svn}), grep (BSD grep) 2.5.1-FreeBSD
awk: /usr/bin/awk, awk version 20070501
sed: illegal option -- -
usage: sed script [-Ealn] [-i extension] [file ...]
       sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]
sed: /usr/bin/sed,
cut: illegal option -- -
usage: cut -b list [-n] [file ...]
       cut -c list [file ...]
       cut -f list [-s] [-d delim] [file ...]
cut: /usr/bin/cut,
basename: illegal option -- -
usage: basename string [suffix]
       basename [-a] [-s suffix] string [...]
basename: /usr/bin/basename,
rm: illegal option -- -
usage: rm [-f | -i] [-dPRrvW] file ...
       unlink file
rm: /bin/rm,
mkdir: illegal option -- -
usage: mkdir [-pv] [-m mode] directory ...
mkdir: /bin/mkdir,
xargs: illegal option -- -
usage: xargs [-0opt] [-E eofstr] [-I replstr [-R replacements]] [-J replstr]
             [-L number] [-n number [-x]] [-P maxprocs] [-s size]
             [utility [argument ...]]
xargs: /usr/bin/xargs,
nvm current: v11.1.0
which node: $NVM_DIR/versions/node/v11.1.0/bin/node
which iojs: iojs not found
which npm: $NVM_DIR/versions/node/v11.1.0/bin/npm
npm config get prefix: $NVM_DIR/versions/node/v11.1.0
npm root -g: $NVM_DIR/versions/node/v11.1.0/lib/node_modules
@n1kk

This comment has been minimized.

n1kk commented Nov 16, 2018

For now I got around it by wrapping nvm sourcing into a function and calling it when I need node access, since I don't need it often.

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

[[ -n "$NVM_INIT" ]] && nvmi

But I think this needs to be looked in. I know 2s is not a big deal but still, from 0.3 to 2.4 is quite a delay.

@ljharb

This comment has been minimized.

Collaborator

ljharb commented Nov 16, 2018

@n1kk the cause continues to be largely the same; anything that calls into nvm use (like nvm auto) also calls into nvm_die_on_prefix, which calls into npm config get prefix, and invoking npm config is slow.

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