Completion takes 10-15 seconds to show on on wsl archlinux

[Malpha]

sample completion on asciinema.

To reproduce, on wsl archlinux

• install elvish.
• type a command and tab to get completion.
• It take 10 ~ 20 sec sometimes to get the completion showing.

[Qi Xiao]

Can you share the output of "all $paths", and tell me if it gets better if you manually set paths to be a smaller list? Windows tends to accumulate a lot of directories in its PATH, which is not a good combination with relatively slow disk IO...

[Qi Xiao]

Oh, and WSL by default inherits Windows's PATH I think, and IO is even slower across the subsystem boundary.

[Malpha]

This is the current list

Manually setting the paths to a small list gives me the expected responsiveness

[Malpha]

Is redefining paths, the only solution?

[Qi Xiao]

I'd recommend that you use it as a workaround for now (most of the Windows binaries are probably not that useful from WSL) but I'll look into adding caching.

[Malpha]

Okay, where can I add a note for WSL users, until the caching mechanism is implemented? Because I thought it was a bug in Elvish. Other WSL users might face a similar issue and think it's a problem with Elvish. I think documenting this temporary workaround would be a good idea, what do you think?

[Qi Xiao]

I guess having this issue in the issue tracker is good enough for now.

[Malpha]

Then I will leave this issue open, Thanks for helping out.

[Kurtis Rader]

Manually setting the paths to a small list gives me the expected responsiveness

That is because you have removed paths that require WSL to map Unix filesystem operations to Windows filesystem operations. This is fundamentally not an Elvish problem. You should see this slowdown in any command run in a WSL environment (e.g., the find command) that performs filesystem operations on paths to the Windows environment. I can't see any practical way for Elvish to "cache" the results. If Elvish performs a command lookup that results in a "not found" error and caches that result how will it know that the cached result is stale after the command is added to a PATH directory regardless of whether it exists on the Windows or Linux environment? The only way such caching can work reliably is if there is a file system monitoring capability to asynchronously be notified if a directory in $PATH has been modified. And that is unlikely to exist now or in the immediate future.

[Qi Xiao]

Manually setting the paths to a small list gives me the expected responsiveness

That is because you have removed paths that require WSL to map Unix filesystem operations to Windows filesystem operations. This is fundamentally not an Elvish problem. You should see this slowdown in any command run in a WSL environment (e.g., the find command) that performs filesystem operations on paths to the Windows environment. I can't see any practical way for Elvish to "cache" the results. If Elvish performs a command lookup that results in a "not found" error and caches that result how will it know that the cached result is stale after the command is added to a PATH directory regardless of whether it exists on the Windows or Linux environment? The only way such caching can work reliably is if there is a file system monitoring capability to asynchronously be notified if a directory in $PATH has been modified. And that is unlikely to exist now or in the immediate future.

It is still on Elvish to make the default experience better. Right now the UI would entirely freeze while waiting for the completion results.

Also, I think you're supposed to respond to my comment regarding caching instead of @Ultra-Code, who was just reporting that their experience.