Asynchronous Namespace Preload?

[dhleong]

While chasing down a "slow file opening" issue caused by my fireplace-based syntax highlighting, I noticed that the s:repl.preload operates synchronously, which seems to be my bottleneck. Would you be open to a PR that makes this operate asynchronously, or do you think that would introduce too much complexity?

[tpope]

Why is s:repl.preload slow? It does little more than call require.

[dhleong]

It's only really the first time it gets called on a fresh REPL that I notice it. Other than "REPL warmup" I'm not familiar enough with the internals to say for sure. The effect is most obvious for me with this repro: - Start a fresh REPL (currently using deps.edn with cider-nrepl and refactor-nrepl middleware) - Open a relatively small file - :Connect to the REPL, directly supplying port and path - Navigate to the .core namespace file via netrw/vinegar and open it My highlighting plugin triggers on BufReadPost and BufWritePost but only uses async fireplace calls. After opening the first file, opening new files has just maybe 100ms delay to it. `s:repl.preload` the only thing making a blocking call so I believe it's the cause, but I can experiment in a fork with making it async to further test the theory.

…

On Sun, Aug 25, 2019 at 11:24 PM Tim Pope ***@***.***> wrote: *Why* is s:repl.preload slow? It does little more than call require. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#368?email_source=notifications&email_token=AAGHIFTFRJAWYBQZQTCSVGDQGNEHNA5CNFSM4IPJIYK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5DE3VI#issuecomment-524701141>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGHIFRIADA7W5LFC7HID7DQGNEHNANCNFSM4IPJIYKQ> .

[tpope]

I think preloading asynchronously when evaling asynchronously would be reasonable.