Determine where speed improvements can be made

[mockdeep]

It appears that avn is a bit slow to change versions with nvm. Both avn and the nvm switch are taking over one second on my system. The nvm speed issue can be tracked at creationix/nvm#926.

Updates above made by @wbyoung, original comment from @mockdeep:

nvm is a little slow to switch node versions, so it would be nice if avn would check the current running version of node before triggering the switch. If it's already loaded, might as well avoid the work.

[ljharb]

@mockdeep if nvm is slow to switch versions (something nobody has reported before) please file an issue on https://github.com/creationix/nvm with nvm debug output, and other relevant info, so I can fix it. Thanks!

[mockdeep]

@ljharb done. After comparing to rvm, I'm not sure if it belongs here or there, since I'm wondering if they do the change asynchronously on directory change.

[wbyoung]

@mockdeep it sounds like both avn and nvm are performing a bit slowly for you. The combined slowdown sounds a bit disappointing.

A goal I had with avn was to keep as much written in node as possible. The easy solution would be to add checks in the shell component for not switching versions, but that's more shell code that I'd like to avoid.

I'd prefer to track down why there are speed issues to begin with. It's possible that avn is loading too many dependencies and slowing down your load times (especially if you're using a spinning hard drive).

What I don't want to do is add this functionality to address your issue and not address the underlying speed issues. The additional functionality will just be more code to support & test and doesn't actually get at the root of this issue.

Speed issues are always tough, and my suggestion would be for you to profile it a bit. This will mean digging in and adding profiling output to the code base and running your altered version, then reporting back on where the most time seems to be spent.

[wbyoung]

@mockdeep, can we get system stats here including CPU speed & details on your hard drive?

[mockdeep]

@wbyoung I'm running an Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz and an SSD. If you have any tips on where I can get started profiling I'd be happy to help.

[wbyoung]

@mockdeep sorry for the delay. I'd recommend just altering the code directly within ~/.avn and adding some log lines and try to figure out where the slowest parts are. Start in ~/.avn/bin/avn.sh with some time commands, then extend to the actual code that's running within ~/.avn/lib and either log the time it takes for something to happen or even just terminate the process before things finish with process.exit(0).

[xinshangshangxin]

I also find it is slow when use avn-nvm does it resolve?

[wbyoung]

@xinshangshangxin any help you can provide tracking down the cause of this would be appreciated.

[kelsin]

For me, avn-nvm is slow when executing the nvm list part of matching which plugins will work for the version in question.

[em]

Extremely slow here as well. Terminal sessions take 10 seconds to initialize with avn on.

[nielsgl]

Same here, zprof shows that it takes 90% of the time spent loading my shell.

[chrisjensen]

I'm finding avn takes about 7s when I cd into a project folder.

I put some echos in the shell script and console.log's in the javascript in to help trace the hold up.

The bulk of the time seems to be in listing the versions, which I can confirm, if I do nvm list it takes about 4 seconds to execute.

BUT if I execute nvm list 5 it's done in under a second.

I tried hardcoding 'list 5' in the nvmCommand call, but that didn't change execution time. So I suspect the delay then may be starting the shell. Sourcing nvm adds about 2s to my shell startup, and nvmCommand then calls source 'source $NVM_DIR/nvm.sh', so that means that during rvm chpwd, source nvm would be getting run twice during nvmCommand('list') - once by my .bashrc and again explicitly by putting it as the first command.

I don't know enough about the nvm / avn architecture on how to avoid this.

Here's the debug output, each level of * represents a new timer.

$ cd project
* Start: (0 ms)
* Found file (13 ms)
* Start eval (25 ms)
** Within NODE **
** lib/hooks.js:62 (chpwd) ...
** 1 ms -  end of init (lib/hooks.js:62 (chpwd))
** 46 ms -  start of match version (lib/hooks.js:62 (chpwd))
*** listVersions start
*** 6 ms - listVersions finished
*** Executing NVM command list ...
*** 3398 ms - findVersions starting...
*** 3407 ms - findVersions finished
** 3817 ms -  start of output (lib/hooks.js:62 (chpwd))
avn activated 5 (avn-nvm v5.12.0)
** 3820 ms -  end of output (lib/hooks.js:62 (chpwd))
* NODE finished: (4513 ms)
* evaling actions: nvm use v5.12.0 > /dev/null;
* Evaled result (7622 ms)
* Evaluated (7632 ms)

[chrisjensen]

I traced my shell startup problem to the one mentioned here for nvm.

Adding the --no-use flag halves my .bashrc startup time, but doesn't have a noticable impact on avn speed.

[wbyoung]

@chrisjensen thanks for all the details. Personally, I'm using n because of speed related issues.

[NickTikhonov]

avn should run faster when the correct version is already applied. Currently, avn takes the same amount of time regardless of whether the correct version is already loaded. Does the package currently implement this check?

[wbyoung]

@NickTikhonov, the determination of a version matching is complex for various reasons. For instance, 8.0 can mean use any patch version for that minor release. Additionally, matching on the node version in the PATH is not the same as allowing nvm to activate a version. The system version could be an exact match, but the version nvm would activate could be at a different location and have different global modules. For these reasons, avn specifically delegates this decision to the underlying version manager.

[ljharb]

nvm use X when X is already used should be very fast, fwiw (if it's not, please file an issue)

[wbyoung]

@NickTikhonov @ljharb we do an nvm list before doing the nvm use. The goal of that code is to return the appropriate command to execute in the shell so that avn can execute it. If there's a simpler (and faster) command to match an the installed/active version, then we could probably update that code to be much faster in the avn-nvm plugin… @NickTikhonov PR welcome based on @ljharb's further guidance.

[ljharb]

@wbyoung hmm - nvm ls 4 will pre-filter the list for you, so you shouldn't need to do your own matching, but there's also nvm version X which will return the single version that resolves to (that should be fast).

[wbyoung]

Thanks, @ljharb.

@nicktikhonov a PR based on this would be welcome and likely address the issues you’re facing.

[chrisjensen]

For those still stuck with this waiting for a patch. I've found making this change on my system dramatically improves the speed of changing directories:

Edit ~/.avn/plugins/avn-nvm/index.js

Change the function installedVersion on lines 184 to comment out two sections

var installedVersion = function(matching) {
  console.log(matching)
  return Promise.resolve()
  .then(function() {
    return resolveVersion(matching);
    // Promise.all([
      // resolveVersion(matching),
      // listVersions(),
    // ]);
  })
  // .spread(function(parsedVersion, versions) {
  //   var parsedMatching = parsedVersion !== 'N/A' ? parsedVersion : matching;
  //   return findVersion(versions, parsedMatching);
  // });
};

[kg-currenxie]

For those still stuck with this waiting for a patch. I've found making this change on my system dramatically improves the speed of changing directories:

Edit ~/.avn/plugins/avn-nvm/index.js

Change the function installedVersion on lines 184 to comment out two sections

var installedVersion = function(matching) {
  console.log(matching)
  return Promise.resolve()
  .then(function() {
    return resolveVersion(matching);
    // Promise.all([
      // resolveVersion(matching),
      // listVersions(),
    // ]);
  })
  // .spread(function(parsedVersion, versions) {
  //   var parsedMatching = parsedVersion !== 'N/A' ? parsedVersion : matching;
  //   return findVersion(versions, parsedMatching);
  // });
};

Nice. Halved my cd speed from ~5s to ~2.5