asking because Linting unused public vars for whole project took 382950ms 😅

yeah, I found that issue and know how to fix it

basically that feature is:

if lint-project-files-after-startup? is enabled (true as default), it will lint all files from your project to have informations like how many errors/warnings your project has, exmple on emacs modeline:

it doesn't affect any linter though

this is the heavier feature of clojure-lsp and depends on the project size, I tested on one of the biggest services on Nubank, and took 391838ms , but Remeber this run async and should not affect performance that much

on other medium/small projects, it's quite fast

TLDR the exception was that I was not using async/>! but async/put! which doesn't have backpressure 😅

I dread the day I must do something non-trivial with core.async, I can barely write working synchronous code 🙂

yeah, clojure-lsp is not a heavy case of async, but I already learned a lot of async with it 😛

hmm... I added :linters {:unused-public-var {:level :off}} to my .lsp/config.edn but it seems clojure-lsp still performs the unused var linting. was this a known issue or am I doing something wrong?

oh, I need to update the docs about that, if you want to disable the public lint, you need to do that on clj-kondo side, add {:linters {:clojure-lsp/unused-public-var {:level :off}}} to your .clj-kondo/config.edn

hmm.. that did not seem to have any effect. I assume the clj-kondo config is read when I restart emacs and not cached anywhere?

just to confirm, you want to not lint public var for your files, right?

yeah. or more precisely: I don't want clojure-lsp to consume one of my cpu cores for ~5 minutes every time I (re)start emacs and I assume that the culprit is that unused-public-var linting

alright so, the best approach is not that

but disable :lint-project-files-after-startup?

I've already done that

(or at least I've attempted to do that)

hum, I just checked the code, and I found the performance issue is some lines before that one

yeah, I'll make a fix to check that flag before the code that is heavy

I assume that :lint-project-files-after-startup? false is doing something, because I no longer get those "a/b/c" counters for the errors and warnings

yes, but the heavy calculation is being done yet

I made a fix on master https://github.com/clojure-lsp/clojure-lsp/commit/0e279b54a31364ceaae70e085e4107a8a212780f

could you test from master branch?

Just like I mentioned here: https://github.com/clojure-lsp/clojure-lsp/issues/506#issuecomment-893520237

sure, I'll report back my findings 👍

thanks!

the issue seems to be resolved 🎉

Good 🙂 I have plans to improve somehow that part of clojure-lsp, but i'll not be an easy task

I also noticed that a) it seems to be running over java (as you mentioned) and b) the "analyzing source paths" parts was about 30% faster than previously (22 seconds vs. 35) and it used multiple cores simultaneously

hum, let's wait next release (I'll do a fix release soon) to test the graalvm binary one

sure. Can I try to do the graalvm build or does it require some additional magic/setup?

oh, that'd be great

https://clojure-lsp.github.io/clojure-lsp/building/#graalvm

seems to be working ok. The "analyzing source paths" seems to be running on a single core and as such takes a bit longer than the java version (32 seconds on native). And if I re-enable the :lint-project-files-after-startup? flag we get back to the "single core saturated for ~5 minutes" situation (for both the java and the native image).

those fast "didOpen", "documentHighlight" et al seem to be quite a bit faster on the native version vs. the java (no surprise there)

yeah, graal takes a little more time for those analysis but consume less resources in general

and I suppose you have a huge project

usually I can't notice the analysis difference

actually for medium/small projects I notice graal is faster

yeah, I think this is in the ballpark of 150-200k lines

Have you also bumped clj-kondo pretty please?

It contains a bugfix for Windows

it's using 2021.08.03

https://clojurians.slack.com/archives/CHY97NXE2/p1628027952138800?thread_ts=1628026691.137100&cid=CHY97NXE2

it contains the fix on master, but it wasn't released yet. ah well

nobody complained so far

but in theory Calva windows users should be able to notice this...

Yeah, otherwise my bump bot would catch that hehe

the analysis fails

I think

due to some Window path thing

I will bump to latest kondo so

I'm releasing a fix including this bump as well

thanks!

let's discuss the issue in a thread please 🙂

Sure

Here's a thread 🙂

Does the issue only happens in the new version?

Literally just installed this release.

Going back to previous version

2021.08.03-13.33.03 no issues

that's odd, maybe some bad compiled binary, let me check

could you test the clojure-lsp one from the releases page?

from here: https://github.com/clojure-lsp/clojure-lsp/releases/tag/2021.08.05-18.25.54

I did

Okay, will try that

❯ clojure-lsp --version
clojure-lsp 2021.08.05-18.25.54
clj-kondo 2021.08.03

firing up vim

gone ape

A whole screen full of Uncaught exception: Header must provide a Content-Length property.

that's odd, this kind of message looks a issue with the client

can you get server<->client json requests logs?

2021-08-05T18:59:33.957Z daffy INFO [clojure-lsp.server:410] - Starting server...
2021-08-05T18:59:33.959Z daffy INFO [clojure-lsp.nrepl:21] - ====== LSP nrepl server started on port 39019
2021-08-05T18:59:33.962Z daffy INFO [clojure-lsp.server:295] - Initializing...
2021-08-05T18:59:33.975Z daffy INFO [clojure-lsp.source-paths:137] - Using given source-paths: ["src" "test"]
2021-08-05T18:59:39.670Z daffy INFO [clojure-lsp.crawler:162] - Analyzing source paths for project root /home/david/development/workspaces/foo
2021-08-05T18:59:41.818Z daffy INFO [clojure-lsp.crawler:121] - Paths analyzed, took 2.1473644 secs. Caching for next startups...
2021-08-05T18:59:41.947Z daffy DEBUG [clojure-lsp.server:?] - :initialize 7984ms
2021-08-05T18:59:41.955Z daffy INFO [clojure-lsp.server:341] - Initialized!
2021-08-05T18:59:41.955Z daffy DEBUG [clojure-lsp.server:?] - :initialized 0ms
2021-08-05T18:59:41.987Z daffy DEBUG [clojure-lsp.server:?] - :didOpen 31ms
2021-08-05T18:59:42.155Z daffy DEBUG [clojure-lsp.server:?] - :didOpen 167ms
2021-08-05T18:59:42.324Z daffy DEBUG [clojure-lsp.server:?] - :codeLens 5ms
2021-08-05T18:59:43.961Z daffy DEBUG [clojure-lsp.server:?] - :semanticTokensFull 5ms
2021-08-05T18:59:45.007Z daffy WARN [clojure-lsp.feature.diagnostics:85] - Invalid clj-kondo finding.  Cannot find position data for {:type :unresolved-var, :filename "/home/david/development/workspaces/foo/redis.clj", :message "Unresolved var: mapv", :row nil, :col nil, :end-row nil, :end-col nil, :level :warning}
2021-08-05T18:59:45.064Z daffy INFO [clojure-lsp.feature.diagnostics:148] - Linting whole project files took 3258ms

is from clojure-lsp

Literally nothing has been updated on the client

no new coc, no new vim, nadda

just clojure-lsp updated

And, going back to the release of 2 days ago, of clojure-lsp, no issues.

that's weird, we need the json logs to debug it

because clojure-lsp is sending/receiving the same data, the integration-tests prove that

so nothing has changed on the Content-Length of the responses

Something is up with codelens

the request is being sent, but no reply is coming back

dm'ed you a link

I can't see any issues with that json log :thinking_face:

we need to confirm this doesn't happen with other users

maybe @UEENNMX0T can test latest release with vim?

Well, all I can do is report what I see. The release of 2 days ago works. Todays release does not.

I pushed out a release to Arch, now I'm going to have to revert that

Yeah, sorry I'm trying to confirm/understand the issue

i use vim 8.2, no code lens so i can’t test that part, i’m sorry

i upgraded to the same version @U11EL3P9U and don’t see any errors in my coc.nvim logs

thanks, I'm double checking the changes

glad to help

Let me turn off codelens (and I'm on neovim 0.5.0)

Yup

codelens enabled == a page full of errors

codelens disabled == all is fine

I think I found the issue 😄

one missing println This doesn't fail on emacs because lsp-mode safelly handle the server response while neovim seems to doesn't like

will do a release fix + clj-kondo bump which I missed

@U11EL3P9U Would you mind testing the clojure-lsp master? you can generate the binary with just make

sure

heating up my CPU right now 😉

Looking good!

❯ clojure-lsp --version
clojure-lsp 2021.08.05-18.25.54
clj-kondo 2021.08.04-SNAPSHOT

codeLens enabled, no errors being spat out on vim

nice, I'll release a fix, sorry for the problems

Thank you for solving it quickly. 🙂

looking good.

Good 😄