This performance issue does seem to be somewhat namespace dependent. Namespaces with fewer dependencies don’t have quite as severe of a performance issue.

TBH right now I’m not sure if the performance correlates more with the number of dependencies or the overall file size. The example above is a relatively small file of 600 lines.

Could you share what versions did you test and if you tested with clojure-lsp master? Also, rolling back Calva doesn't affect the used clojure-lsp

we had some improvements recently on completion performance both on latest release and master (not released yet)

I’m currently testing off the 2022.04.18-00.59.32 release.

I can give master a try as well. I’m using the make file do produce a build and configured Calva to use my local build.

yeah, it'd be good to test on master, algo, if you have a public project where we could test it as well

Unfortunately don’t have a public project. Another thing to note is my company uses a monorepo setup. We have one root “virtual” project that encompasses all of our dependencies across the repo, so the classpath is quite large.

Though the reason I bring this up now is it does seem to be a regression as of the past couple days/weeks. I don’t know exactly when I started seeing it.

maybe try older releases could help find the release that introduced that regression, I was not aware of any regression, actually we improved lots of performance things on completion recently, it's kind of surprising 😅 maybe we missed something though c/c @U07M2C8TT

Building off master branch now 🤞

Oh what do you know, much faster 😁

It seems like the clj-kondo evaluation time hasn’t improved much, but it no longer blocks other code actions or autocompletes?

nice, so probably we fixed on @U0BUV7XSA’s recent commit :)

no, we didn't change anything regarding block code actions or autocompletes

That’s interesting. Previously it looked like code actions were blocked until LSP was completely finished, but now I see my snippet suggestions even while LSP is still computing. Either way it’s much better now.

By the way on an unrelated note, I can’t say this enough but LSP is a GAME CHANGER!!

Intereting, maybe some change on vscode api that calva's use, I don't know too much about it tho haha, glad you like it 🚀

@UQE9SS4DP, as the logs show, completion waits for kondo analysis. that hasn’t changed, nor have we done anything recently to improve kondo performance. but @U0BUV7XSA recently fixed a performance problem in completion related to aliases, which aligns with what you were seeing. my guess is that you’re seeing better performance because the initial completion request now completes faster. subsequent completion requests will still wait on kondo analysis. also keep in mind that editors tend to do their own filtering of completion items, so often the sequence goes like this: 1. type 1 character 2. editor asks clojure-lsp for completions; it returns a massive list 3. type a few more characters, editor filters the original list. It may look like clojure-lsp is giving you a narrower list, but this is actually all thanks to the editor 4. sometimes the editor asks clojure-lsp for more completions; it returns a smaller list All that is to say that the time for that first completion request is really critical, and subsequent completion requests that wait on kondo analysis are less important

I usually disable Emacs lsp-mode's completion cache, so I can always know how much time clojure-lsp takes, a dev thing only tho

@U07M2C8TT thanks for the detailed explanation, that makes sense! I haven’t done a lot of work with LSPs, so wasn’t sure which end is responsible for something like debouncing rapid input.

Most of the time, LSP servers should handle multiple requests and debounce on their side

I’m still learning about them too—complicated beasts. There’s debouncing on both sides, just one part of many latency/throughput tradeoffs