lsp 2025-12-15

What is costing so much ram in clojure-lsp? I have some clojure-lsp processes that take like 5 GB of ram, It's my bottleneck these days šŸ˜„

in the meantime šŸ˜„

Code analysis that come from kondo during startup, it depends how big is your project, you can tune to disable keyword analysis or symbols for example but that will disable features for those

so it's just at the beginning and then the jvm greedily hold on to the ram?

would be awesome if clojure-lsp was a unique process then šŸ˜…

clojure-lsp holds the data structures in memory

Also having a single process would not help that much as it would hold different projects data, summing everything in a single process besides being harder to manage, although its an old idea that it's not trivial to support

(I must admit I maxed out the RAM for my new machine with clojure-lsp in mind šŸ˜… )

yeah me too I'm really pissed my motherboard has issues with 256gb so I had to downgrade to 128gb and now it freezes but because I reache it all the time

šŸ‘€ 1

128gb isn't enough...?

then clojure-lsp likely won't be the issue unless you have dozens of projects?

yes I do

Yeah, I have 16GB ddr5 and it's not a issue, you must be using multiple projects at the same time?

And I use 3-4 projects at the same time

damn emacs starting a lsp-sever every time I open a file in a project šŸ˜„

Sounds like misconfigured project root

Wow, that explains it

wdym misconfigured project root?

I can imagine that the fact that my main project is cloning some core libraries for facilitate editing the code adds up to how much it has to index?

If you open files of the same project, lsp-mode should use the same running server

no but it is the same project but different worktrees

Like a mono repo?

maybe try using a single clojure-lsp for the whole thing

no worktrees are like a branch but instead of checking out and screwing your current wip you go into a different directory

Just having a single project root with configured settings for other source paths, dunno, would need to understand better your arch

It's not clear yet to meet how your folders look like, if there is more than a deps.edn/project.clj etc

You could try lsp-remove folders

one oddity is that I clone multiple projects in a .local-repos to make it easier to read the source and edit it

that may explain the size of some lsp instances

one of the reasons I haven't really explored git worktrees is precisely this, as I would expect to get a LSP process per worktree. Just like if you checked out the same git repo multiple times into separate directories (e.g. for different branches) and then opened each as separate projects.

exactly and it kinda sucks because fundamentally there isn't much difference between 2 worktress, so with clojure immutable datastructure inner workings it could even be really cheap to have worktrees if it was natively understood by clojure-lsp

baically just the diffs

hehe unfortunately it's not that easy, but having a common project root would be the start for that

I would imagine efficiently constructing and sharing the analysis data between two arbitrary projects (be they similar worktrees of a single codebase or totally different projects) would be almost impossible šŸ™‚ But sometimes I've naively wondered if the startup time could be improved by hashing the namespace tree and caching the analysis or parts of it.

The fun thing is: we already do that, we cache analysis by file hashes

@jacob.maine helped with that years ago, and helped a lot the performance

šŸŽ‰ 1
1

I noticed tho we only do that for external analysis https://github.com/clojure-lsp/clojure-lsp/blob/f555e4b89a1a3aa8aa9f66809f0d5e4dc034c61d/lib/src/clojure_lsp/startup.clj#L127, IIRC it was for consistency to avoid cache something of the project that might changed, but not sure that's something that would happen

if the infrastructure is already(?) there, I wonder how much work would it require to extend that to cover project files too? perhaps guarded by a setting so that users can opt-in, in case there are issues. we have thousands of namespaces in one of our projects, some of which haven't been touched in years (or decades), so it would be cool to see how much of an effect such caching might have.

yeah agree, we can explore that

šŸ‘ 1

fwiw, I’m using worktrees and have similar issues. The worktrees often share 99%+ code.

āž• 1