Clojurians Log v2

after the last update lsp has become practically unusable, am i the only one with this problem?

even adding a comment and saving it causes a freeze

:didChange 10143ms :codeAction 88ms :codeAction 73ms :documentHighlight 4ms :hover 67ms :codeAction 730ms

oh, did-change is spending too much time for some reason

did you notice if is related only with latest version or some older one?

@snoe mentioned a slowness but we didn't find anything relevant yet and I'm not seeing those did-change peaks

I updated lsp yesterday, before that it was ok

for curiosity, how many lines your buffer has?

1038

Do you know what version you were using before that?

No, but I should be able to find it soon. I still have the terminal open where I updated, I just need to go ~10000 lines up 🙃

aur/clojure-lsp-bin              1:2021.04.27_20.17.45-1 -> 1:2021.05.06_19.44.00-1

the logs haven't always accurately covered how long the didChange took, so if you might have to time from the client if you start spelunking history

exactly ☝️ 😕

@huxley could you try the <https://github.com/clojure-lsp/clojure-lsp/releases/tag/2021.04.27-20.17.45|2021.04.27-20.17.45> and check if looks smoother for you? (ignoring the didChange time on log as it will be incorect)

sure, as soon as I remember how to downgrade package in arch

@dharrigan maybe knows 🙂

done

I will check already if it is better

Remember that there is the project scan startup time if deps were changed

I restarted lsp, opened the buffer again, waited for it to load and tested in the same place as before and it is much better

thanks! good to know I'm not crazy 🙂

Nice, so indeed it was `https://github.com/clojure-lsp/clojure-lsp/releases/tag/2021.05.06-19.44.00 that introduced that

I always get all the bugs stuck, so if something doesn't work for someone somewhere, I'm definitely one of those people

Maybe this @snoe https://github.com/clojure-lsp/clojure-lsp/commit/857bdc186e5585771c3b50b2c444065fb2b2e018 Still I don't know why

when I watch diagnostics for the old version and new version come they are just coming in faster, so I suspect it's not that, but how much processing anaylze-changes is doing

thanks colleagues for your work, I appreciate it ❤️ , but I have to get back to my

@huxley do you use vim or emacs?

@snoe maybe vim is waiting for did-change for some reason? That change, made did-change only end after changes were analyzed

emacs

if I had to guess, although I don't know emacs and elisp, there is a problem with asynchronicity somewhere, because the main thread of emacs is blocked to the point that even the cursor was changing and ctrl-g didn't help

odd, I didn't notice anything on medium/big projects

I suppose there is no easy repro for that right?

It looks like there isn't

If there is anything I can do to help, I am happy to do so.

We need to repro the issue to make sure a possible fix would solve that 😕

@ericdallo no, the client is still responsive but the diagnostics update like 1 letter at a time since thats being sent from clojure-lsp. a good project to repro this stuff is editing clojure core repo code. core.clj by itself to start and make sure did-change there is relatively fast.

@snoe I tested on clojure.core and indeed took 28s of freezed emacs after changing a single char 😱

So I imagine the didChange change on latest version caused that?

Yeah, the previous release is way faster for some reason

Oh it's faster but it still take a long time to update lsp things like diagnostics document highlight

but it's better then freezing buffer

Alright, we need to rollback that, but then we will face the issue I solved with that commit, concurrency on other methods while didChange didn't update the file :document with the changes

We probably can do sync the file change computation but leave kondo run to async, that probably would be the best approach, WDYT @snoe?

yeah, the 28s is related with kondo run, the file change computation is really fast

Alright, I'll try to make a fix that will fix both issues 🙂