Clojurians Log v2

Left is new?

yeah

Nice, a 1gb win

Made some (low hanging fruit) optimizations and publishing a new version now. I'm seeing a bit better performance even compared to the previous version and all without caching. There's more optimizations I could do but those require a bigger change (captured that into an issue for the future).

Awesome, thank you both for the help! Will bump clojure-lsp in a few mins

nightly build available

@lasse.olavi.maatta would be nice if you could re-lint your project. what I'm seeing locally is that it is now even slightly faster than before and better memory behavior, but YMMV

I ran the clojure-lsp diagnostics a few times; I discarded the first run after switching versions as that always seemed to be a bit slower: • 2025.06.13-20.45.44: about 33.9 - 34.2 s cpu time • 2025.07.25-15.41.15-nightly: 35.8 - 35.9 s • 2025.07.26-16.45.48-nightly: 32.2 - 33.4 s

no dramatic change in the memory usage when opening a projet between versions .25 - .26, as far as I can tell.

I assume that build isn't quite ready year -- I reloaded VS Code and got an error downloading lsp nightly.

yes, it will be available in a few mins and post in #clojure-lsp-builds

Thanks!

Got the new version, and it seems to have run successfully on our big project at work.

Any difference in speed or memory usage?

is there some specific way to benchmark the speed / memory use you'd suggest to make things easy to compare? I can test on our largeish project, but I'd love to provide exact numbers if I only knew how

I don't pay much attention to startup speed or memory usage so it's hard for me to say. I suspect for ongoing performance, I might notice more when working on HoneySQL, since that lags a bit...

I'm wondering if people will notice memory difference if we are passing a xms of 2gb in clojure-lsp

Maybe run the command line version of LSP to see if diagnostics runs slower or equally fast

indeed, clojure-lsp diagnostics

I ran clojure-lsp diagnostics from the command line a few times without clearing the cache; 2025.06.13 took about 34 s cpu time, 2025.07.25 took 36 - 37 s so just a bit slower.

thank you for testing @lasse.olavi.maatta! would you consider it a large project?

No idea how accurate these are, but I used some random psrecord tool to graph the cpu and memory graphs (of the lsp process itself) while running the diagnostics from the cli. Looks like the memory use is quite a bit smaller with the new version.

yes, I'd love to know how much we can decrease https://github.com/clojure-lsp/clojure-lsp/blob/d679c4d2d8d41b76a3296d89f2e5f66f9f5b84a9/cli/build.clj#L62 / https://github.com/clojure-lsp/clojure-lsp/blob/d679c4d2d8d41b76a3296d89f2e5f66f9f5b84a9/cli/deps.edn#L32

the problem with clojure-lsp memory was always clj-kondo initial lint when starting, if we improved that, we can certainly touch that limit

for clojure-lsp it's especially relevant that after the initial lint, all (or most) memory is freed, which is now the case

I measured 28mb heap before linting and after linting (after forcing a GC)

all by removing memoize usage which turned out to not be so beneficial especially when having large configs...

Intereesting

here's the graphs for the first 120 seconds from opening a project in emacs with lsp-mode.

a good benchmark we use at nubank (suggestion from @andreribeirocamargo):

find .clj-kondo -mindepth 1 ! -name config.edn -exec rm -rf {} + && find .lsp -mindepth 1 ! -name config.edn -exec rm -rf {} + && time clojure-lsp diagnostics

basically removes the cache so clj-kondo analyzes the classpath again, which is what take most of time usually.

and since clj-kondo has no cache now, in the future we will need to remove only lsp cache

Clj-kondo does have a file cache, just not in memory

To clarify, I just removed memoize usage which keeps stuff around in memory forever, if you keep the memoized function around

Yeah my bad, I got it but mentioned the wrong cache 😅