Whenever a change is made to a file, the client can send only the lines it was changed or the full text document updated

Usually the incremental helps for huge buffers

But I could not make it work perfectly yet, giving some outdated buffers bugs

That's why full is the default yet

Ah I see. Is there an audit of the buffer bugs? Just out of curiosity

I don't remember exactly what was the issue, but It was not something easy to fix and it was making clojure-lsp really unusable 😕

Ah ok 😞. An emacs-specific bug yeah?

not really, should happen for all clients

I intend to go back and take a look, but I'm trying to prioritize some other things

Ah ok yea, no worries 🙂 Was just curious

Every one in a while I notice my laptop fans spinning loudly and see that clojure-lsp is using quite a few of my cpu cores

Nothing appeared in the logs for a few minutes, then about a dozen lines of :completion 150000ms (the duration ranged from 130 to 150 seconds).

Sounds a bit similar to this issue on Calvahttps://github.com/BetterThanTomorrow/calva/issues/1250

It seems I can trigger this quite consistently by doing something like (get-in m [:foo :bar :zed :lol :kek ..... It seems that typing each kw triggers a new completion attempt and typing enough keywords fast enough consumes all the cores

Oh, wow, sounds like a great find!

I assume that normally :completion shouldn't take that long, but I'm dealing with a rather huge project and I assume that trying to do completion just takes longer than in a smaller project and it's easier to trigger multiple concurrent completion attempts (which just escalates the problem further)

I think I see this too. Sometimes completions, sometimes they don't. Although it doesn't bother me too much. I do wonder though, any possible optimizations that you can think of @UKFSJSM38?

We need to confirm it's related to completion indeed or completion is taking more time because it:s waiting for the didChange process async like in the calva issue

Could you elaborate the repro please?

I'll try to figure out in more detail what's going on and whether or not I can isolate the problem to a simple reproduction outside my main project. Originally, today while working with some code, I noticed that anytime I typed a sequence of consecutive keywords, clojure-lsp would end up consuming 4-6 cpu cores for a few minutes. For example if I had (let [x (get-in m [:x |])] ... (where | is my cursor), and I quickly typed 5 more keywords into the lookup vector -> cpu usage would rise and after a while the clojure-lsp log would show a bunch of :completion lines. I also checked that this also happens in an empty ns with no requires.

Yeah, quite odd behaviour, a repro would certainly help

a couple of very un-scientific tests and observations: • Everything seems to work fine in a bare bones lein new app foo project. Typically the duration in the :completion logging is just dozens of ms and the cpu usage is low. After a few times after trying really hard I managed to get a few random cases of approx 1000 ms, but the change in the cpu usage is minimal so it's really hard to notice. • I added a whole bunch of top level dependencies (`lein deps :tree` prints something like 300+ libraries) to the project, but didn't :require any of them. Now it was much easier to see how the cpu usage climbed when typing lots of keywords. Instead of seeing values like 1000 ms rarely, I could consistently see multiple cpu cores being utilized for several seconds and the :completion durations in the range of 5000 ms. Again, I could see how several lines of :completion <some value near 5000ms> were printed after the cpu usage had been high for a few seconds. • Setup ◦ I deleted the .lsp directory between tests ◦ I recreated the .clj-kondo cache between tests and linted the classpath as described in the clj-kondo "project setup" chapter. ◦ No configuration for lsp or clj-kondo

that helps a lot actually, probably the computation in the completion inside clojure-lsp is considering keywords from external deps, which probably doesn't make sense

I didn't confirm that, but I can try to take a look, could you pass that repro with those deps later?

or open an issue with that

sure, I can try to push this to github tomorrow. I need to sanitize the deps a bit as they contain some private libraries not available on clojars etc.

and to be clear, my state-of-the-art way to trigger this was to type a lot of short keywords really really fast, ie. (get m [:q :w :e :r :t <imagine 30 keywords here> .. 😄

https://github.com/neoclide/coc.nvim/issues/1649

This issue was done, so I guess call hierarchy will work on coc?

clojure-lsp already supports that from server side