REPLCompletions: async cache PATH scan

[IanButterworth]

Fixes #52765

In shell> when first typing a word tab completion hinting searches the entire PATH list for completions again and again for every char entry.

On slower systems the hinting can make typing quite slow because of this i.e. #52765

This treats the contents reachable by PATH as static for a given session unless the PATH string changes, by caching it once at startup async and then if PATH changes at tab-completion time.

A modification would be to instead do something like update the cache on an async timer.

Base.generating_output() || Timer(t->REPLCompletions.cache_path(), 0; interval=60)

[IanButterworth]

Some numbers

Natively on an M2 Mac

% JULIA_DEBUG=REPLCompletions ./julia -q -t2
julia> ┌ Debug: caching PATH files took 0.011616084 seconds
│   length(pathdirs) = 13
│   length(path_cache) = 1563
└ @ REPL.REPLCompletions ~/Documents/GitHub/julia/usr/share/julia/stdlib/v1.11/REPL/src/REPLCompletions.jl:334
julia> 

with -t1 it takes 0.036s.

On a Windows VM via Parallels on the same M2 Mac

> $env:JULIA_DEBUG="REPLCompletions"
> ./julia -q -t2
julia> ┌ Debug: caching PATH files took 0.245052708 seconds
│   length(pathdirs) = 16
│   length(path_cache) = 5127
└ @ REPL.REPLCompletions \\Mac\Home\Downloads\julia-1efddebd6b\share\julia\stdlib\v1.11\REPL\src\REPLCompletions.jl:334
julia>

with -t1 it takes 0.46s

Clearly it's a good thing to do based on these Windows numbers, and I think @topolarity has durations in the many seconds on WSL.

[vtjnash]

I very much don't like this happening (even in the background) just because REPL happens to be loaded. But I like that it would be cached. Probably should just be cached per-statement though? Seems very awkward if rm("foo") and touch("foo") don't work correctly

[IanButterworth]

Moving to per statement sounds good. I think we do want to do it in the background still, just because of the pathological case @topolarity has on WSL where the PATH scan takes > 5s

Seems very awkward if rm("foo") and touch("foo") don't work correctly

Note that this is for files reached by PATH only. Files in the current dir, or a specific path aren't cached, so your examples won't change behavior.

[vtjnash]

Yes, the change to move to the background (when first needed by that statement) is very good too. We should try not to run arbitrary computations in the REPL/UI task which more properly belong to a worker task (until the user hits tab).

[IanButterworth]

Ok. I've moved it to cache in a worker thread at the first moment it would be needed, which is likely to be a hint when typing initially in shell>, meaning the completion might not be available for that char because it doesn't wait at all, but should be on most systems for the next char. (with -t2 caching takes 0.01s for me).

Side note. I noticed we don't provide these PATH completions for command strings. That seems logical to add.

[vtjnash]

meaning the completion might not be available for that char because it doesn't wait at all

Not waiting does seem optimal to me. Lag is generally bad. Can we hook into the refresh_wait worker Task though, or similar, so that as soon as the completion becomes available that is gets the completion printed (unless it is canceled and restarted by the next character being pressed)?

[vtjnash]

Side note. I noticed we don't provide these PATH completions for command strings. That seems logical to add.

Side side note: we use completely different code for completions inside shell> and backtick'd command strings, where the completions for shell are significantly better than those available for backticks. We should fix that.

[IanButterworth]

Can we hook into the refresh_wait worker Task though..

Sounds good. I think that's what #52847 is trying to achieve

[IanButterworth]

Come to think of it, if #52847 is done, then cache_PATH() could be done (if needed) synchronously in complete_path and the whole completion calculation would be async on a worker thread, with the appropriate delayed update/cancel.

[topolarity]

Yeah, crawling PATH is quite slow on my WSL2 instance since WSL automatically appends the Windows PATH to the Linux one:

┌ Debug: caching PATH files took 25.125992393 seconds
│   length(pathdirs) = 36
│   length(PATH_cache) = 7730
└ @ REPL.REPLCompletions ~/repos/julia/usr/share/julia/stdlib/v1.11/REPL/src/REPLCompletions.jl:338

Even so, with the latest changes the shell feels immediately responsive 👍

The Julia start-up time also looks comparable to before this PR, and it still seems to have useful auto-complete for many commands while it continues scanning.

Overall, it feels much better than before. Thanks!

[IanButterworth]

0.01s vs 25s... YMMV... Good to know we can handle that case nicely.

I'll go ahead and merge when CI is green

[vtjnash]

I think we should also rescan every command? How do we make sure this gets periodically refreshed so when the user changes the filesystem (e.g. installs a missing package), the completions aren't wrong afterwards?

[IanButterworth]

Makes sense. Where would you call this? I'm a little lost in where to.

[IanButterworth]

How about we spawn it every time it's needed, unless its already running?

[vtjnash]

True, it could be interesting to spawn an update almost continually if the past one is finished