This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-19
Channels
- # announcements (15)
- # babashka (4)
- # beginners (55)
- # calva (92)
- # cider (70)
- # circleci (1)
- # clj-kondo (136)
- # cljdoc (2)
- # clojars (11)
- # clojure (48)
- # clojure-australia (1)
- # clojure-europe (30)
- # clojure-nl (3)
- # clojure-sweden (2)
- # clojure-uk (7)
- # clojurescript (40)
- # conjure (5)
- # core-async (11)
- # cursive (55)
- # data-science (1)
- # datomic (10)
- # degree9 (2)
- # development-containers (15)
- # events (1)
- # fulcro (14)
- # gratitude (13)
- # helix (5)
- # lsp (35)
- # malli (10)
- # meander (18)
- # off-topic (24)
- # pathom (13)
- # polylith (12)
- # practicalli (6)
- # re-frame (13)
- # reagent (33)
- # reitit (4)
- # remote-jobs (1)
- # shadow-cljs (13)
- # spacemacs (31)
- # specter (1)
- # stepwise (2)
- # tools-deps (19)
- # vim (1)
- # xtdb (7)
Browsing the settings doc
• text-document-sync-kind - What are the tradeoffs of :full
vs :incremental
? And why is :full
the default?
Whenever a change is made to a file, the client can send only the lines it was changed or the full text document updated
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?
I intend to go back and take a look, but I'm trying to prioritize some other things
are there any known performance issues regarding :completion
?
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
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
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.
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?
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> ..
😄