Fork me on GitHub
#lsp
<
2021-05-13
>
ribelo19:05:03

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

ribelo19:05:35

even adding a comment and saving it causes a freeze

ribelo19:05:14

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

ericdallo19:05:29

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

ericdallo19:05:43

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

ericdallo19:05:22

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

ribelo19:05:53

I updated lsp yesterday, before that it was ok

ericdallo19:05:58

for curiosity, how many lines your buffer has?

ericdallo19:05:27

Do you know what version you were using before that?

ribelo19:05:40

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 🙃

😅 3
ribelo19:05:16

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

snoe19:05:38

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

ericdallo19:05:58

exactly ☝️ 😕

ericdallo19:05:08

@U0BBFDED7 could you try the and check if looks smoother for you? (ignoring the didChange time on log as it will be incorect)

ribelo19:05:37

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

ribelo19:05:01

I will check already if it is better

ericdallo19:05:05

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

ribelo19:05:30

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

snoe19:05:58

thanks! good to know I'm not crazy 🙂

ribelo19:05:49

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

😆 3
snoe19:05:16

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

ribelo19:05:12

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

ericdallo20:05:40

@U0BBFDED7 do you use vim or emacs?

ericdallo20:05:18

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

ribelo20:05:35

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

ericdallo20:05:37

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

ericdallo20:05:52

I suppose there is no easy repro for that right?

ribelo20:05:30

It looks like there isn't

ribelo20:05:40

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

ericdallo20:05:43

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

snoe22:05:56

@UKFSJSM38 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.

ericdallo22:05:02

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

ericdallo22:05:49

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

ericdallo22:05:17

Yeah, the previous release is way faster for some reason

ericdallo22:05:43

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

ericdallo22:05:55

but it's better then freezing buffer

ericdallo22:05:58

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

ericdallo22:05:53

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

ericdallo22:05:11

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

ericdallo22:05:45

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

ericdallo01:05:42

@U0BUV7XSA could you review that later please https://github.com/clojure-lsp/clojure-lsp/pull/424? It was the best working approach I found and I'll keep testing it this week on that branch. It would be great if you could test it as well @U0BBFDED7 (just run make on the project root to generate a non native binary clojure-lsp enough for the testing)

practicalli-john09:05:40

If it helps, I'm using lsp-mode <tel:202105101947|20210510.1947>, on Emacs 27.1, gnu/linux without any performance issues

thanks 3