[Refactor] Speedup nvm_list_aliases() / nvm ls

[PeterDaveHello]

The same trick as how did we speed up installation script.

Origin time spent for 1000 times nvm_list_aliases & nvm ls:

$ time for a in {1..1000}; do nvm_list_aliases > /dev/null; done                                                                             

real    16m38.301s
user    1m24.416s
sys     1m21.192s

$ time for a in {1..1000}; do nvm ls > /dev/null; done                                                                                                              

real    20m55.143s
user    2m4.852s
sys     1m57.508s

New time spent for 1000 times nvm_list_aliases & nvm ls:

$ time for a in {1..1000}; do nvm_list_aliases > /dev/null; done

real    11m59.601s
user    2m0.272s
sys     2m23.560s

$ time for a in {1..1000}; do nvm ls > /dev/null; done

real    13m31.442s
user    1m55.320s
sys     2m11.132s

[ljharb]

Unfortunately this causes the results to be listed in nondeterministic order. Parallelizing is only really safe if output is captured and then joined together later; the nvm_print functions output to stdout.

[ljharb]

Specifically:

master:

$ time nvm alias
airbnb -> 4.6.2 (-> v4.6.2)
default -> node (-> v7.9.0)
loopback -> loopback (-> ∞)
node -> stable (-> v7.9.0) (default)
stable -> 7.9 (-> v7.9.0) (default)
unstable -> 0.11 (-> v0.11.16) (default)
iojs -> iojs-v3.3 (-> iojs-v3.3.1) (default)
lts/* -> lts/boron (-> v6.10.2)
lts/argon -> v4.8.2
lts/boron -> v6.10.2

real	0m2.225s
user	0m0.967s
sys	0m1.387s

PR:

$ time nvm alias
loopback -> loopback (-> ∞)
airbnb -> 4.6.2 (-> v4.6.2)
default -> node (-> v7.9.0)
stable -> 7.9 (-> v7.9.0) (default)
unstable -> 0.11 (-> v0.11.16) (default)
node -> stable (-> v7.9.0) (default)
iojs -> iojs-v3.3 (-> iojs-v3.3.1) (default)
lts/argon -> v4.8.2
lts/boron -> v6.10.2
lts/* -> lts/boron (-> v6.10.2)

real	0m1.363s
user	0m1.061s
sys	0m1.608s

[PeterDaveHello]

It'll be nondeterministic order but predictable, as the related commands use really a long time to finish the output, I wonder how can we make this acceptable to save some time? Thanks.

[ljharb]

It's definitely one of the slower parts of nvm and I'd love to speed it up.

However, I'm not sure how to do so without rearchitecting the entire process - currently it says "for each alias, resolve it, colorize it, output it" - I think it'd have to be "grab all aliases → resolve all aliases → colorize all aliases → output all aliases", but I don't think POSIX has enough control structures to be able to do that cleanly.

[PeterDaveHello]

So I wonder if this is how best we can do currently, as it's predictable, and also saving about 0.9 sec on your computer?

[ljharb]

When you say "predictable", I'm not sure how it could be since there's no guarantee that the items (within a category) will resolve in the same order every time.

[PeterDaveHello]

@ljharb it's now ordered by the time spent on each command, I'm now testing it using:

for a in {1..100}; do nvm ls &> $a; done

to see if the results the same, I think it should be.

Another question, if the minor order (as you can see, the upper order was not changed, pre installed versions first, and aliases, and LTS) changed, which part will be affected?

[PeterDaveHello]

Oops, interesting results ...

61%

stable -> 7.9 (-> v7.9.0) (default)
unstable -> 0.1 (-> v0.1.2) (default)

39%

unstable -> 0.1 (-> v0.1.2) (default)
stable -> 7.9 (-> v7.9.0) (default)

Other parts are the same.

A little bit stupid, but I'm now testing with 1000 rounds to see what's the different on the rates.

[PeterDaveHello]

62% vs 38%, almost the same 👀

[ljharb]

Any nondeterminism is problematic.

[PeterDaveHello]

So if the unstable / stable problem been fixed this will be good?

[ljharb]

Yes, if the PR output matches the master output deterministically, this seems great.

It would be ideal, but not required, to beef up the test coverage on this though, if possible :-)

[PeterDaveHello]

Now use sort to fix the out of order output. Tests all passed. Also updated the benchmark on the first comment.

[ljharb]

I'm still concerned this will cause some ordering issues in the future, but for now this seems good :-)