Performance issues on man completions

[StripedMonkey]

Basically the title. Completions can take up to a second or more, a quick count reveals I have 57124 manpage entries on my system. The initial completion taking a while may be reasonable, however, I believe what makes it not reasonable is attempting to do something along the lines of

• man git-<tab> (examine results)
• c takes a few seconds to appear again, then any subsequent additional characters triggers a complete regeneration of search list. This makes typing the rest of the manpage name unreasonably slow.

I have a handful of suggestions to make this better, namely caching at minimum entries in man -w so there is not nearly as much filesystem traversal, but I wanted to get opinions.

[fdncred]

Out of curiosity, I'd be interested if you see a speed improvement if you compile nushell differently using this command.

cargo install --path . --features=extra,dataframe,mimalloc

or if you install from crates.io

cargo install nu --features=extra,dataframe,mimalloc

I've noticed some fairly significant performance increases with mimalloc

[StripedMonkey]

Using --features=extra,dataframe,minalloc doesn't seem to change it by more than a second or so out of ~7s. On a related note, is there no builtin time command? Funnily enough I don't seem to have it installed, as it's a bash/zsh builtin.

[fdncred]

is there no builtin time command?

What do you want from a time command, the name itself is a bit ambiguous. We have date now and we have timeit.

[StripedMonkey]

time as is consistent across bash, fish, zsh, etc. measures the wall, user, and system time a particular command runs for: i.e

[monkey@monkeydragon ~]$ time du -hs ~/
956G	/home/monkey/

real	 0m56.042s
user 0m1.849s
sys	 0m25.028s

It's useful for measuring the time it takes for a script/process to complete but in particular allows you to examine how much time the program spends doing things like syscalls Vs running the program itself Vs wall (real) time. In the above example, notice that the du -hs ~/ command itself only spent ~1.8s of "CPU Time" doing something, while the system spent almost 13x as long on whatever filesystem operations were required. This tends to give you an idea of how much overhead you have, since system time is pretty hard to improve upon.

timeit is only measuring wall time, which isn't strictly as useful, although it was indeed what I was looking for in this instance for wall time.

[StripedMonkey]

So, for results for the difference between the default allocator and the minalloc: Using the command taken from the man-completions.nu

timeit { man -w | str trim | split row (char esep) | par-each { glob $'($in)/man?' } | flatten | par-each { ls $in | get name } | flatten | path basename | str replace --regex ".gz" "" }

Default:

3sec 385ms 885µs 606ns
3sec 265ms 374µs 398ns
3sec 418ms 164µs 279ns
3sec 312ms 227µs 90ns

Minalloc:

2sec 847ms 773µs 463ns
2sec 836ms 90µs 184ns
2sec 924ms 620µs 7ns
2sec 883ms 285µs 974ns

There is definitely some extra overhead from the completions itself, but I'm not sure how to time the character press to completions becoming available, which seems to be an extra 4ish seconds on top of this.